monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-11-16 15:58:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Missing meeting logs since 6/17

Browse source
This commit is contained in:
el00ruobuob 2019-07-20 23:52:56 +02:00
parent d447b0ac6d
commit 471ccd9efa
No known key found for this signature in database
GPG key ID: 8794A50E11FE51A0
11 changed files with 1707 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

78
_posts/2019-06-20-logs-for-the-tini2p-dev-meeting-held-on-2019-06-20.md Normal file
View file

@ -0,0 +1,78 @@
---
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.

237
_posts/2019-06-30-logs-for-the-dev-meeting-held-on-2019-06-30.md Normal file
View file

@ -0,0 +1,237 @@
---
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.

117
_posts/2019-07-01-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-07-01.md Normal file
View file

@ -0,0 +1,117 @@
---
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

85
_posts/2019-07-04-logs-for-the-tini2p-dev-meeting-held-on-2019-07-04.md Normal file
View file

@ -0,0 +1,85 @@
---
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

294
_posts/2019-07-06-logs-for-the-Community-meeting-held-on-2019-07-06.md Normal file
View file

@ -0,0 +1,294 @@
---
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
**\<midipoet>** i will see what they say. if people are serious
**\<rehrar>** sure, why not?
**\<rehrar>** can't have too much Monero in your life, right?
**\<dEBRUYNE>** I like the idea of a yearly konferenco
**\<sgp\_>** We definitely need some event over there that's all about Monero
**\<dEBRUYNE>** And it is perhaps worthwhile to switch between Europe and NA
**\<rehrar>** and there's a lot of people that missed this past Konferenco
**\<rehrar>** ick
**\<rehrar>** just do two
**\<rehrar>** different content, different people, different konference
**\<el00ruobuob\_[m]>** Maybe in Paris we could have some Quarkslab or Trezor folks to come for some talks?
**\<rehrar>** let's discuss after meeting
**\<rehrar>** kinda interested to see this as a thing
**\<dEBRUYNE>** Ledger is from France too iirc
**\<sgp\_>** Sure, we can table this. Looks like people are interested
**\<dEBRUYNE>** rehrar: Twice a year seems to be a bit excessive though
**\<midipoet>** i have sent a text/message to see if they would be up for helping.
**\<sgp\_>** Defcon + KonferencoNA + KonferencoEU + C3 (+ HCPP?) is a lot
**\<sgp\_>** Defcon will be more promotional in future years though
**\<rehrar>** you're telling me
**\<rehrar>** Defcon and C3 are other people's things though, and are more about promotion (as you said) than focused discussion
**\<sgp\_>** Yes, they will shift to be more promotional as time goes on
**\<sgp\_>** What time of year are we thinking?
**\<midipoet>** same time next year, no?
**\<el00ruobuob\_[m]>** oups, correcting myself: Trzor = Prague, Ledger Paris (as dEBRUYNE said)
**\<sgp\_>** Moneroversary April, Konferenco June, Defcon August, C3 Dec/Jan
**\<sarang>** Zcash did a different color lanyard if you didn't consent to be photographed
**\<sarang>** Nice idea
**\<dEBRUYNE>** June would have decent weather too in southern europe
**\<dsc\_>** Russia also an option
**\<sgp\_>** is it like 30C there then?
**\<dsc\_>** sgp\_: yes
**\<rehrar>** another vote for russia
**\<sgp\_>** dsc\_: I unfortunately wouldn't feel comfortable going to Russia, but others may feel it's a good idea
**\<rehrar>** could go visit in laws
**\<midipoet>** i am going to say a greek island
**\<rehrar>** wish suraeNoether was here
**\<dsc\_>** sgp\_: I feel more comfortable going to Russia than US, as US wants to know everything about me to get a travel VISA
**\<dEBRUYNE>** Barcelona would probably be a suitable location too
**\<rehrar>** dsc\_ just likes Russian women
**\<rehrar>** don't be fooled
**\<dsc\_>** I mean... :-P
**\<sgp\_>** it's a personal thing, I would be less safe in Russia unfortunately
**\<dsc\_>** It would indeed
**\<midipoet>** we have spent a lot of time on hypothetical locations
**\<sgp\_>** I will table this for now and see what Brandon was thinking of, but there definitely seems to be a lot of EU interest
**\<sgp\_>** Thanks for your excitement everyone
**\<sgp\_>** 5. Workgroup report
**\<sgp\_>** a. Daemon/CLI workgroup
**\<sgp\_>** 0.14.1 was finally released a few weeks ago
**\<sgp\_>** including reproduceable builds
**\<sgp\_>** I don't have much to say except it was a large update. Any devs can chime in if they want
**\<sgp\_>** b. Localization workgroup
**\<sgp\_>** ErCiccione bid farewell to their organizer position to focus on other initiatives
**\<ErCiccione[m]>** :)
**\<ErCiccione[m]>** but i'm still working on weblate,
**\<sgp\_>** https://www.reddit.com/r/Monero/comments/c06vuw/my\_last\_proposal\_as\_coordinator\_of\_the/
**\<monerobux>** [REDDIT] My last proposal as coordinator of the Localization Workgroup has ended. A recap, some updates, plans for the future of the internationalization of Monero and a huge thanks (self.Monero) | 77 points (94.0%) | 22 comments | Posted by ErCiccione | Created at 2019-06-13 - 15:01:35
**\<ErCiccione[m]>** it's installed on the server and i'm just configuring it. It will be ready soon.
**\<xmrscott[m]>** Woot woot
**\<sgp\_>** very nice
**\<el00ruobuob\_[m]>** cool!
**\<rehrar>** bye ErCiccione[m]. You will be missed.
**\<rehrar>** Press F to pay respects
**\<sgp\_>** ErCiccione[m]: are there any other updates or comments you would like to leave us with?
**\<ErCiccione[m]>** goodbye all
**\<dsc\_>** :'(
**\<sgp\_>** :'(
**\<ErCiccione[m]>** except i'm not going anywhere
**\<midipoet>** wait, i thought you weren't leaving, and just pivoting
**\<midipoet>** oh jeepers
**\<midipoet>** that ws sad for a sec
**\<ErCiccione[m]>** midipoet: none of the two, i'm dedicating more time to some non-monero thing i'm working on and other monero things i'm interested in :)
**\<sgp\_>** I look forward to seeing the localization workgroup continue to do great things
**\<midipoet>** all good in the hood
**\<sgp\_>** c. GUI workgroup
**\<sgp\_>** 0.14.1 was released earlier this week
**\<sgp\_>** dsc\_: anything you want to mention?
**\<dsc\_>** Tails user experience is currently pretty horrible (for beginners I guess)
**\<dsc\_>** I have a colab. going on with someone from the Tor/deepweb/tails/shady/underground/cyberpunk community that actually uses Tails so next release will see Tails integration
**\<sgp\_>** You obviously wasted your time on the light theme /s https://usercontent.irccloud-cdn.com/file/Q074KonZ/blockfolio%20theme%20poll
**\<dsc\_>** Hey, I just make what the community tells me to
**\<rehrar>** the light theme needs a lot of improvement
**\<rehrar>** not anybody's fault per se
**\<dsc\_>** You need a lot of improvement
**\<dsc\_>** Sorry rehrar, continue?
**\<rehrar>** :D
**\<dsc\_>** lol
**\<rehrar>** the white theme needs to be rethought. The contrast is very poor in most areas.
**\<rehrar>** The type needs to be bigger since the background is yelling at you, scanning is harder with small type
**\<rehrar>** although the type could be bigger for black theme too
**\<dsc\_>** Have you tried calibrating your monitor's contrast?
**\<rehrar>** oh yes, let's just tell every user to calibrate contract
**\<dsc\_>** We can def. do some improvements there Rehrar, I mostly agree
**\<rehrar>** I turned it on today
**\<rehrar>** and turned it off after a few moments
**\<rehrar>** but hey
**\<rehrar>** baby steps
**\<dsc\_>** I'd suggest to create an issue on Github.. Or keep reminding us in #monero-gui to up the contrast and such.
**\<sgp\_>** On a related note, I've been meaning to finally open an issue on the network settings. I'll get to it eventually since it's important for 0.15
**\<ErCiccione[m]>** not many use the white theme apparently, i wouldn't put too much efforts in that
**\<rehrar>** ErCiccione[m]: but maybe not many use it because it's unusable?
**\<dsc\_>** unusable is a big word :-D
**\<ErCiccione[m]>** nah, i think many just use the black theme, that is way cooler IMO
**\<sgp\_>** dark theme is "in" now. It will change back in ~2 years probably
**\<dsc\_>** rehrar: I think I lived up to what was previously designed - I think this is something to take to kneuffelbund first
**\<dsc\_>** Wouldnt you agree?
**\<midipoet>** i am waiting for the 3D theme
**\<sgp\_>** lol
**\<selsta>** if it’s unusable for you it’s definitely something with your monitor
**\<midipoet>** or his eyes
**\<selsta>** it’s a black font on white background? :P
**\<dsc\_>** developers trying to convince a graphics designer his monitor is off - goodluck :D
**\<rehrar>** probably. Not blaming you dsc\_
**\<rehrar>** come to defcon dsc\_ I mis syou :'(
**\<selsta>** your eyes need to adjust when going from dark to light mode
**\<dsc\_>** Did the earthquake move Las Vegas out of the US? Ill come
**\<rehrar>** selsta: tiny black letters
**\<sgp\_>** I'm going to move on, thanks for feedback rehrar and your update dsc\_
**\<dsc\_>** No, just a sec
**\<selsta>** Are you using Windows on a high dpi display?
**\<dsc\_>** So Tails integration is coming up. In addition, I'm working on including the Monero GUI guide directly into the GUI
**\<rehrar>** we'll talk after meeting guys
**\<dsc\_>** After that ill work on Tor/i2p
**\<dsc\_> \</report>**
**\<rehrar>** nice!
**\<sgp\_>** thanks for completing the report
**\<rehrar>** Tor/i2p is thrilling
**\<sgp\_>** seriously
**\<sgp\_>** Tails is also cool
**\<dsc\_>** You'd be suprised how large that userbase is
**\<sgp\_>** get some good cred points at Defcon
**\<sgp\_>** speaking of which....
**\<sgp\_>** d. Defcon workgroup
**\<sgp\_>** The Defrcon schedule is finalized. We have 20 talks, 7 workshops, dozens of puzzles, and several activities planned. Rehrar, sarang, midipoet, and me talked on Jitsi for 3 hours of planning yesterday. This year will be totally awesome.
**\<sgp\_>** I won’t go into too much more detail here since we just had the Defcon meeting before this community meeting, but now is the time to look for hotels and airfare. Please have yourself heard in #monero-defcon so we can help you out. We are always looking for more volunteers before and during the event.
**\<sgp\_>** Questions -> #monero-defcon
**\<sgp\_>** 6. Open ideas time
**\<rehrar>** wait
**\<msvb-mob>** And information on planning is available as well https://taiga.getmonero.org/project/michael-defcon-vegas/
**\<rehrar>** oh never mind
**\<sgp\_>** It’s open ideas time! Feel free to propose your ideas to this discussion group, and feel free to comment on others’ ideas. If you disagree with the idea, please reply with constructive criticism. Thank you!
**\<msvb-mob>** Any hardware questions?
**\<dEBRUYNE>** re: Tor/I2p integration, to avoid complexity, we are probably going to stick with either one
**\<sgp\_>** I'm a big proponent of i2p to punch through firewalls to connect to home nodes
**\<msvb-mob>** What happened to tinyi2p? I thought oneiric liked that one?
**\<sgp\_>** Not developed yet. WIP
**\<selsta>** oneiric is the dev of tini2p
**\<rehrar>** how's that been going btw?
**\<rehrar>** anyone know?
**\<sgp\_>** well, presumably WIP. I haven't seen much activity lately
**\<sgp\_>** i2p-zero now has deterministic builds too
**\<rehrar>** oof. That's nice.
**\<dEBRUYNE>** Our idea was to bundle i2p-zero with the GUI
**\<ErCiccione[m]>** tini2p has regular meetings. The last one: https://web.getmonero.org/2019/06/07/logs-for-the-tini2p-dev-meeting-held-on-2019-06-07.html
**\<kinghat>** dev updates on tinyi2p is on gitter. i dont check that often.
**\<dEBRUYNE>** Make a checkbox, if ticked -> start i2p and transactions will be pushed over i2p
**\<sgp\_>** ah, that would be why
**\<sgp\_>** Any other ideas/discussions? Or do we just want to talk about what city to choose for the conference?
**\<midipoet>** country first, then city
**\<sgp\_>** Let me formally end the meeting then, discussion can continue after
**\<sgp\_>** 7. Confirm next meeting date/time
**\<sgp\_>** The next community meeting will be in 2 weeks on 20 July at 17:00 UTC. The next Coffee Chat will be on 27 July at 16 or 17 UTC.
**\<sgp\_>** 8. Conclusion
**\<sgp\_>** That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

105
_posts/2019-07-08-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-07-08.md Normal file
View file

@ -0,0 +1,105 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-07-08
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** Righto, let's begin our meeting!
**\<sarang>** Agenda: https://github.com/monero-project/meta/issues/368
**\<sarang>** Starting now with GREETINGS
**\<sarang>** hi
**\<sgp\_>** Hi
**\<sarang>** suraeNoether: you here?
**\<sarang>** It's quiet... too quiet...
**\<suraeNoether>** yes
**\<suraeNoether>** sorry
**\<suraeNoether>** hellow gents
**\<suraeNoether>** harrow
**\<sarang>** Let's jump into ROUNDTABLE then, with our small crowd
**\<suraeNoether>** mine is going to be super fast: last week basically right after the research meeting i started getting very ill. long story short, i went to the hospital, and let me just say: recreational pancreatitis is not a thing for a reason
**\<sarang>** but it'd be a cool name for a band
**\<suraeNoether>** yes. yes. \*strokes chin\*
**\<suraeNoether>** so, i'm trying to take it easy and i did very little this past week
**\<sarang>** Glad to see you're well enough to debug :)
**\<sarang>** For me, MLSAG/CLSAG verification updates continue, with PR 5707 open for review and similar changes to my CLSAG branch (to be included in later code for review)
**\<suraeNoether>** i have a few things on my plate for today, but other than that: i'm basically all action items and no progress compared to last week. onto sarang :D
**\<sarang>** I've been in contact with Aram, the author of the Lelantus paper/protocol; he came up with an interesting idea to make the prover very efficient, at the cost of proof size and verification
**\<sarang>** although the verification cost can be batched, of course
**\<sarang>** I view proving time as generally unimportant (to an extent), but it's a very clever new way to prove a 1-of-N zero commitment
**\<suraeNoether>** good prover times means fast construction of transaction for mobile devices
**\<suraeNoether>** which is v nice
**\<sarang>** true
**\<sarang>** but if it costs you both space and verification time...
**\<suraeNoether>** unlike, say, verification time, which puts a constraint on how rapidly the network can grow, which has security consequences for the chain
**\<suraeNoether>** ^ ah yeah that's true: is it faster with a big space tradeoff?
**\<sarang>** Faster prover, slower verifier, bigger proof
**\<sarang>** I think you can batch away some of the verification increase (you effectively do two smaller proofs)
**\<sarang>** There's a non-public draft writeup already, but I assume he'll work it into the main paper once the modified security proofs are complete
**\<suraeNoether>** oooof
**\<suraeNoether>** very interesting consequences
**\<sarang>** Regardless, it's a damn clever construction
**\<suraeNoether>** i'm excited to read all about it
**\<sarang>** I'll ask if I can send it to you suraeNoether (not public though, sorry)
**\<sarang>** I'm investigating a possible modification to Omniring that splits out the range proofs, improving verification batching at the cost of proof size
**\<sarang>** And, because of the Omniring non-batching currently available, am revisiting analysis of RCT3
**\<sarang>** Which, while it would require a separate output pool (non-compatible key image structure), does allow for batching of proofs (aside from ring member group elements, which cannot be batched unless reused)
**\<suraeNoether>** last we spoke about this, we were still interested in writing up a comparison paper, but you've done all the legwork on it so far
**\<suraeNoether>** still the plan?
**\<sarang>** I don't consider a formal paper necessary, or even a great use of time
**\<sarang>** But analyses of spacetime, totally
**\<suraeNoether>** fair, maybe we can do a blog post on tradeoffs between the three schemes or something
**\<sarang>** Maybe, but it gets subtle and complex really quickly under many different assumptions
**\<sarang>** There isn't really a quick-and-dirty soundbite answer to which is better or worse
**\<sarang>** Depends heavily on input/output structure, use of fixed epochs, batch behavior, etc.
**\<sarang>** and output pool migration is nontrivial
**\<sarang>** Omniring would \_not\_ require this... Lelantus and RCT3 would
**\<sarang>** (or rather, Omniring does not \_require\_ this)
**\<suraeNoether>** see... when you say all that, it seems like it \*is\* a good use of time. maybe not high priority, but
**\<sarang>** A comparison is useful, I agree. But I don't want it to get lost in unnecessary formality of a full paper
**\<sarang>** And a comparison is exactly what I'm doing
**\<sarang>** Any questions on these topics?
**\<sgp\_>** Just a comment to say simple comparisons are good
**\<sarang>** roger
**\<sarang>** Does anyone else have research topics of interest to share?
**\<sarang>** Righto!
**\<nioc>** suraeNoether: people are wondering what the attendance was at konferenco
**\<sarang>** At least provide a range proof
**\<moneromooo>** 26 people and 172 sybils.
**\<nioc>** an article in coindesk mentioned 75 which I know is way low
**\<suraeNoether>** nioc: i'm finishing up my post-mortem report on the konferenco today (on my action item list). We had 150 swag bags made, with around 30-40 leftover, but we had 27 speakers and like 10 sponsors.
**\<nioc>** I estimated 120 just by glancing
**\<suraeNoether>** 75 is the number i gave coindesk for the number of attendees on Saturday morning, but more people bought tickets on both days and the totals were higher
**\<suraeNoether>** if you count speakers and sponsors, that's around 110 on the first day, and around 125 the second
**\<nioc>** think you mran Sunday morning
**\<nioc>** mean
**\<suraeNoether>** nope, we sold tickets throughout the afternoon on saturday and a few on sunday too. but coindesk asked for a comment on saturday morning, so i told them what i had sold at that point
**\<nioc>** I'll wait for the report
**\<suraeNoether>** k
**\<nioc>** thx
**\<sarang>** suraeNoether: congratulations on effectively committing yourself to running a kickass conference annually until the end of time =p
**\<suraeNoether>** it was actually some of the best days of my life, but i've been told explicitly by my doctors that i need to take a vacation
**\<suraeNoether>** so i'm planning for that in august, since scary cardio and internal medicine people told me so with stern voices
**\<sarang>** Well then, let's move on to ACTION ITEMS
**\<sarang>** I have many things in progress. Lelantus proof review, modified Omniring split proof analysis, RCT3 analysis, and starting to put together my defcon talk/workshop
**\<suraeNoether>** my action items: konferenco post mortem, research report for previous quarter, funding request for the next 3 months, and some debuggin
**\<sarang>** I'm doing a talk on transaction protocols (very high level), a workshop on simple cryptographic constructions with Python, and a panel discussion at the blockchain village
**\<suraeNoether>** oh and i'm definitely not going to defcon this year. i can ship leftover swag like our USB data blockers with the monero logo and our pull-up banners if someone sends me the information for it
**\<sarang>** :(
**\<sarang>** The pull-up banners would be nice, assuming it's cheaper to ship than to get new ones
**\<sarang>** as would the USB blockers
**\<suraeNoether>** i'll look into it; ordering the usb blockers may be short notice but i can find out
**\<suraeNoether>** unless you just meant shipping the banners
**\<suraeNoether>** which is cool too
**\<sarang>** Yeah I meant the banners
**\<sarang>** I believe there was an idea to perhaps order more blockers for this (I'm not the one to ask)
**\<sarang>** If you have extra USB blockers and would ship with the banners, cool
**\<suraeNoether>** fantastic, i am happy folks liked the blockers
**\<sarang>** Any last questions or comments before we formally adjourn, since agenda topics have been completed?
**\<sarang>** Going once
**\<sarang>** twice
**\<sarang>** adjourned!
**\<sarang>** Thanks to everyone for attending; logs will be posted shortly on the github issue

48
_posts/2019-07-11-logs-for-the-tini2p-dev-meeting-held-on-2019-07-11.md Normal file
View file

@ -0,0 +1,48 @@
---
layout: post
title: Overview and Logs for the tini2p Dev Meeting Held on 2019-07-11
summary: Current project status, Roadmap, Meta issues, and miscellaneous
tags: [dev diaries, i2p, crypto]
author: el00ruobuob / oneiric
---
# Logs
**tini2p** 0: Greetings
hi
1: Update on alpha release
planned on releasing the alpha version of tini2p yesterday, but ran into a number of bugs while writing the ECIES SessionManager and related tests
some of them were holdovers from early LeaseSet2 code. a number of them though must have been the products of late-night coding or some other mystery
either way, patches are in the ecies branch, where you can also see what I've been working on
I'm going to take another couple weeks to finish up the remaining parts of ECIES, and implement ECIES tunnels according to the draft spec I wrote up: https://gitlab.com/tini2p/meta/blob/master/docs/ecies-tunnels.md
**tini2p** I'll also be writing up spec patches for Prop144 ECIES to make it actually match a secure bi-directional protocol like is claimed
currently, following the spec, it is a one-way protocol with inconsistencies for claims in the "Pairing and Binding" sections
there are also large inefficiencies in the "pictures" that zzz added for HTTP GET and POST examples
they are based on how ElGamal currently works, and imho we should not continue these design failings going forward
there is no legitimate reason to codify the design flaw in specification
**tini2p** for a review of a recent discussion with zzz on the subject: tini2p/meta#19
best I can tell, the biggest reason zzz puts forward for a one-way protocol using one-way Noise handshake patterns is "that's how it works in ElGamal/AES+SessionTags" and "0-RTT means sending payloads with the first packet"
the second reason about 0-RTT I can partially understand, but Noise specifies the IK (two-way pattern) for 0-RTT protocols
payloads can be sent with the first part of the handshake, making it 0-RTT, even in zzz's definition. however, Noise also specifies finishing the handshake with a reply DH to get the full security benefits of the IK handshake
see the tables in "Payload Security Properties": https://noiseprotocol.org/noise.html#payload-security-properties
**tini2p** using the X one-way handshake (never finishing the IK pattern) as zzz suggests weakens the protocol, and leaves it vulnerable to Key Compromise Impersonation attacks
it also leaves the protocol vulnerable to replay, and only guarantees forward secrecy for the sender
imo, those are unacceptable for the streaming (bound) versions of ECIES. especially when we have the opportunity to add protections against those vulnerabilities by just adding the other half of a single round trip
hopefully, zzz will accept the spec diffs, and ECIES-X25519-AEAD-Ratchets will be as strong as it can be
**tini2p** over the next couple weeks then, I will be writing the spec diffs, implementing ECIES Tunnels, and hopefully releasing alpha
fingers crossed I won't run into too many more bugs before then
alpha release will likely only include ECIES-only tunnels, but may include the interop with current ElGamal tunnel building
when ElGamal interop is in-place, tini2p routers will be able to build tunnels through existing ElGamal routers
that is the goal at least
there will still be no client features for alpha release, as I haven't even begun to work on the client-facing functionality
the goal for alpha is to have end-to-end sessions through some form of tunnels with ECIES routers on both ends of the end-to-end session
**tini2p** after that is working, I can move onto fuzz testing the living hell out of my implementation, building client features, doing global cleanup, and add logging, etc.
logging actually may be left to client applications, TBD
anyway, that's it for this short meeting
will check in again next Thursday 2019-07-18 18:00 UTC
@tini2p\_gitlab slides the gaffer slowly across the table

140
_posts/2019-07-14-logs-for-the-dev-meeting-held-on-2019-07-14.md Normal file
View file

@ -0,0 +1,140 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2019-07-14
summary: Development status, Code & ticket discussion, and miscellaneous
tags: [dev diaries, core, crypto]
author: el00ruobuob / rehrar
---
# Logs
**\<dEBRUYNE>** Guess we can start, anyone else here? ping moneromooo, rbrunner, selsta, dsc\_, vtnerd, woodser, hyc, jtgrassie, fluffypony, luigi1111, smooth
**\<xmrmatterbridge> \<rehrar>** Yes meeting. IRC problems. Sec.
**\<dEBRUYNE>** probably forgot some people
**\<fluffypony>** here
**\<dEBRUYNE>** sarang and suraeNoether of course
**\<moneromooo>** I am.
**\<rbrunner>** Here of course, where else
**\<xmrmatterbridge> \<rehrar>** Tor rejecting my login attempts.
**\<xmrmatterbridge> \<rehrar>** But present.
**\<dEBRUYNE>** rehrar, you may lead
**\<moneromooo>** If ypu have a "tor account", that was some phishing site ^\_^
**\<italocoin>** :))
**\<xmrmatterbridge> \<rehrar>** moneromooo, it's my SASL. Broken for some reason. Will fix later.
**\<xmrmatterbridge> \<rehrar>** Anyways. Greetings is done.
**\<xmrmatterbridge> \<rehrar>** So 2. What's been completed since previous meeting.
**\<jtgrassie>** woodser: inc/exc PR moneromooo mentioned https://github.com/monero-project/monero/pull/5598
**\<xmrmatterbridge> \<rehrar>** Anyone have an update? CLI stuff? GUI stuff?
**\<dsc\_>** This week ill work closely with Selsta on things concerning GUI
**\<moneromooo>** More work on share-rpc. More work on banning subnets. Mostly.
**\<rbrunner>** I had a little success today, with making Windows GUI installer builds reproducible, with several people confirming the same hash: https://old.reddit.com/r/Monero/comments/cd0snl/help\_test\_reproducible\_windows\_gui\_installer/
**\<xmrmatterbridge> \<rehrar>** dsc\_ as opposed to other weeks when you don't work closely with selsta on things concerning GUI?
**\<dEBRUYNE>** To add to the GUI, dsc\_ opened a few pull request to improve Tails support
**\<italocoin>** dsc\_ i've tested GUI and works well, any known bugs?
**\<xmrmatterbridge> \<rehrar>** rbrunner what's the time frame you want for that? I can put it in the next Revuo as a volunteer opportunity, but they come out on Thursdays.
**\<dEBRUYNE>** xiphon made a pull request to properly store the integrated address (previously it was stored as plain address + short encrypted payment ID)
**\<rbrunner>** Not sure what you mean about volunteers. I think confirmation is already here, see the posts in that thread
**\<dsc\_>** italocoin: There are always some bugs but must say latest release was a solid one. For problems best to visit our issue tracker.
**\<dsc\_>** rehrar: Yes, exactly
**\<xmrmatterbridge> \<rehrar>** rbrunner, noted. Thanks for the info.
**\<italocoin>** dsc\_ one thing that i think we should worok on, is that when you send yourself a payment, it should be a small note there that was sent to yourself, if not you get sent 0
**\<dsc\_>** italocoin: this has been reported by kico earlier, I believe
**\<italocoin>** that confuses some people
**\<italocoin>** Oh kk
**\<rbrunner>** I think the CLI does the same
**\<italocoin>** true
**\<rbrunner>** also a little confusing, at least at first
**\<moneromooo>** It is impossible to distinguish change from non change, so if you rescan, the amount would change.
**\<italocoin>** for regular people it is confusing for sure, my idea would be just to add a note that was sent to yourself and just show the fee or someting like that
**\<moneromooo>** Though... stoffu made some change to the derivations when he introduced subaddresses, and it might be that they can be distinguished nowadays...
**\<italocoin>** moneromooo: if its sent to subaddress i think you are right, but if the wallet gets rescaned or created again, the 0 its unavoidable i think
**\<xmrmatterbridge> \<rehrar>** Alright nothing else?
**\<xmrmatterbridge> \<rehrar>** Oops. Stupid delay.
**\<rehrar>** from the ashes I rise
**\<rehrar>** ok, next topic
**\<fluffypony>** release?
**\<moneromooo>** Oh yes please
**\<rehrar>** sure
**\<rehrar>** fluffypony: take it away?
**\<moneromooo>** Are you still waiting on the bsd patch, or can that be left out for now ?
**\<fluffypony>** I mean, it would be advantageous to have it
**\<fluffypony>** but if it's going to take more than a few days let's just leave it
**\<moneromooo>** IIRC TheCharlatan said it was a non trivial amount of work.
**\<moneromooo>** Dunno how far it is though.
**\<fluffypony>** ok maybe he comments in the next 24 hours
**\<rbrunner>** "Release" would be already 0.14.1.1 then?
**\<fluffypony>** yes
**\<fluffypony>** would the GUI need a point release too?
**\<dsc\_>** Don't think so. Selsta: ping
**\<selsta>** yes
**\<dsc\_>** yes?
**\<selsta>** I mean yes GUI would need a point release too.
**\<selsta>** We embed the daemon so all the bugs that get fixed on CLI side effects us too.
**\<rehrar>** Ok, anything else you want for the discussion on the point release fluffypony?
**\<dsc\_>** Ah ok, I was more thinking about any death threatening GUI bugs.
**\<fluffypony>** moneromooo: what merges are you waiting for?
**\<moneromooo>** I think they're all merged by luigi1111w now. The one I had been thinking about was 5363, but given I've just had to rewrite a fair bit of it, I think I'll leave it.
**\<moneromooo>** So from my side, we have all we need.
**\<fluffypony>** ok so just version bump?
**\<moneromooo>** And maybe some more hashes (with a bit more slack than last time maybe).
**\<fluffypony>** kk
**\<rehrar>** Is it possible for us to discuss the October fork?
**\<fluffypony>** should we set a threshold?
**\<rehrar>** Just like, prelim stuff
**\<fluffypony>** for hashes I mean
**\<moneromooo>** Last time was a day IIRC, that seemed little to me.
**\<moneromooo>** I suppose we should not see a day's reorg but still
**\<fluffypony>** ok let's say 48 hours from the time of the commit
**\<fluffypony>** that gives us a buffer coz it still needs to be built by a bunch of people etc
**\<moneromooo>** OK.
**\<rehrar>** gucci?
**\<dEBRUYNE>** I guess once fluffypony sets the 0.14.1.1 tag, people can already start their determinisitc build processes and publish the hashes
**\<moneromooo>** versace.
**\<dEBRUYNE>** The more results the better
**\<fluffypony>** yes
**\<fluffypony>** balenciaga
**\<dsc\_>** louie
**\<dsc\_>** -e +s
**\<moneromooo>** To be clear, I was talking about the embedded block hashes, not gitian hashes.
**\<rehrar>** If so,
**\<dEBRUYNE>** moneromooo: Yes, my comment was unrelated to that, should have clarified that
**\<rehrar>** Do we have a rough estimate for when "code freeze" is for this upcoming fork?
**\<rehrar>** also, I don't know if hyc is around, but with the glowing reviews of RandomX, it's looking almost positive that it's going in, yeah?
**\<rehrar>** one more to go in regards to audits
**\<dEBRUYNE>** Not sure about code freeze, but the general idea was to publish binaries way in advance of the fork right (e.g. 4-6 weeks)
**\<dEBRUYNE>** As the consensus changes are soon ready and we don't have to perform last minute tweaks
**\<rehrar>** and sarang hasn't mentioned anything about CLSAG audits, right?
**\<rehrar>** most definitely going in the fork after this one
**\<dEBRUYNE>** Yeah October seems too short for CLSAG
**\<rehrar>** alright, if no other comments, are there any other meeting items?
**\<moneromooo>** I've had people reviewing share-rpc (thanks vtnerd and stoffu), please feel free anyone else ^\_^
**\<dEBRUYNE>** I kind of wanted to ask everyone's opinion on switching to a 12 month schedule after April 2020 (so once RandomX and CLSAG are in)
**\<dEBRUYNE>** So we'd essentially only have one HF each year around Monero's birthday
**\<moneromooo>** We'll only know if we have new stuff we want to add when we get to it.
**\<sarang>** I am still in (slow) talks with potential auditors
**\<sarang>** Nobody's biting for the math review part, only implementation
**\<sarang>** So I am not expecting things will be ready for fall 2019
**\<dEBRUYNE>** moneromooo: So you'd like to retain the 6 month schedule and skip a HF if there are no consensus changes basically?
**\<dEBRUYNE>** Or if they can wait
**\<rehrar>** RandomX will have just been implemented for six months at that part. Is that enough time to gauge it? Becasuse if not, and we move to a year schedule, then that means we wait a full year if something meh happens.
**\<moneromooo>** I find it annoying to say in advance "we'll wait that long" when we have no clue yet whether that predefined delay will be appropriate.
**\<rbrunner>** Er, that sounds a little too much theory. I don't think we would wait and not emergency-HF
**\<rehrar>** it's true that it is a year away at least, so it's hard to gauge. A lot can happen in a year. But I can appreciate dEBRUYNE just putting the feelers out
**\<moneromooo>** Oh, anyone knows of any merchant/exchange/whatever that's switched from long payment ids recently ?
**\<rehrar>** no
**\<dEBRUYNE>** A bit unrelated, but I plan to contact some staff from Bitfinex, Binance, and Bittrex on Reddit to have a chat with them about switching
**\<dEBRUYNE>** Those are basically the largest 'offenders'
**\<moneromooo>** Thanks
**\<italocoin>** RandomX: is experimental, do we have reviews from outsiders?
**\<moneromooo>** Yes, three.
**\<moneromooo>** See hyc's "RandomxAudits" github repo.
**\<rehrar>** with a fourth on the way
**\<italocoin>** trustworthy?
**\<moneromooo>** That's what you decide after reading them.
**\<rehrar>** it wasn't my grandma who audited the thing, if that helps
**\<rehrar>** either way, I think we can call it here.
**\<italocoin>** That is great news
**\<rehrar>** Discussion may, of course, continue after the fact.
**\<italocoin>** hhaha rehrar
**\<rehrar>** Thanks for attending the meeting everyone!
**\<rehrar>** have nice lives

213
_posts/2019-07-15-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-07-15.md Normal file
View file

@ -0,0 +1,213 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-07-15
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** Let's start
**\<sarang>** GREETINGS
**\<suraeNoether>** howdy everyone
**\<suraeNoether>** anyone else here? :P
**\<sarang>** I suppose we can continue anyway
**\<sarang>** ROUNDTABLE
**\<sarang>** suraeNoether: care to begin?
**\<suraeNoether>** Sure. First, dEBRUYNE: I got an aswer from Jerry Brito re your question about bitlicense
**\<hyc>** hi
**\<sarang>** Can you repeat the question?
**\<sarang>** (for our logs)
**\<suraeNoether>** yes: dEBRUYNE was wondering if I could ask jerry brito about the possibilities of how Monero can work with the NYDFS bitlicense
**\<suraeNoether>** the example of Zcash being something that recently been listed on coinbase, etc, indicating that the NYDFS gave their blessing somehow
**\<sarang>** This is Zcash's compliance brief: https://z.cash/wp-content/uploads/2019/04/Zcash-Regulatory-Brief.pdf
**\<sarang>** You may find it useful
**\<suraeNoether>** it turns out that we have it backwards: exchange businesses or money transmitting business need to get valided through the NYDFS, and the reason that zcash was listed on coinbase had more to do with how much contact zcash has had with the coinbase team
**\<suraeNoether>** so, rather than having coincenter talk to NYDFS, what we need to do is start having meetings with people at coinbase, or gemini, or whichever platform we are discussing
**\<suraeNoether>** dEBRUYNE: does that make sense?
**\<dEBRUYNE>** Yes, thanks
**\<dEBRUYNE>** sarang: Also -> https://www.dfs.ny.gov/about/press/pr1805141.htm
**\<sarang>** Sure, it doesn't really make sense to have a protocol validated by a regulator anyway
**\<suraeNoether>** right
**\<sarang>** Wait, what?
**\<suraeNoether>** okay, moving past regulation
**\<sarang>** That press release specifically identifies assets
**\<sarang>** I don't really know what that means
**\<sarang>** This is why I am neither a regulator nor a lawyer :/
**\<suraeNoether>** well, let's move on and discuss it in a bit
**\<sarang>** Perhaps they go to regulators with a specific version or something, I dunno
**\<sarang>** sure
**\<suraeNoether>** a konferenco post morto update
**\<sarang>** s/morto/mortem ?
**\<suraeNoether>** latin or esperanto?
**\<sarang>** -\_\_\_\_-
**\<suraeNoether>** lol
**\<suraeNoether>** so anyway, i spent the past week doing a few things wrapping up the konferenco, including organizing the budget projected vs actuals
**\<suraeNoether>** and writing these four guide documents. THESE ARE INTENDED TO BE LIVING DOCUMENTS, UPDATED REGULARLY BY KONFERENCO ORGANIZERS.
**\<suraeNoether>** they are not commandments in stone.
**\<suraeNoether>** https://github.com/b-g-goodell/mrl-skunkworks/tree/master/Konferenco
**\<suraeNoether>** they are to be debated and argued
**\<suraeNoether>** sarang and i were debating funding structures earlier
**\<sarang>** vigorously
**\<suraeNoether>** KonGuide.docx is a general guide for maybe how things can go in the future
**\<suraeNoether>** i recommend even if you disagree with my budgeting/finance recommendations (with respect to the CCS or something), move past that and read the organizational part of the document
**\<sarang>** One note... using markdown instead of docx is much better for version history on git
**\<sarang>** (and displays natively via github)
**\<suraeNoether>** if someone wants to convert it, i'd love that
**\<suraeNoether>** i've been braindumping into libreoffice
**\<suraeNoether>** KonGuideKO.docx is designed for konferenco organizers
**\<suraeNoether>** this includes a list of things to do to get ready for the konferenco, including checklists at the end
**\<suraeNoether>** KonGuideSC.docx is designed for the "steering committee" which will probably have whoever is financially liable for the konferenco sitting on it. they make final budget decisions and sign contracts.
**\<suraeNoether>** KonGuideCC.docx is designed for the "content committee" which will be deciding on speakers and inviting them, and organizing the schedule
**\<sarang>** What are a couple/few things (briefly) you would have done differently, in hindsight?
**\<suraeNoether>** well, budgetarily, this was a nightmare. there were three very large sources of red on the budget sheet that should have been addressed
**\<sarang>** If you would have been able to more regularly cash out the CCS (or done it in chunks), would that have solved the problem?
**\<suraeNoether>** firstly, the original CCS request was designed to ask for 60,100$ but by the time I actually received it, it was worth $28,500 or so. waiting until it was done in one big chunk and then transferring it to me introduced so much time into the equation for price that volatility ate a lot of the money.
**\<sarang>** Not good for the organizers or donors
**\<sarang>** (they don't know the eventual value of their donations)
**\<suraeNoether>** one way to rectify that could be regularly withdrawing from the funding as it goes, another way would be to have funding take place in stages
**\<suraeNoether>** secondly, our turnout was much lower than we had all hoped
**\<sarang>** What if you raised money based on when different things needed to be purchased? Like the venue, or food, or A/V support, etc.
**\<sarang>** Then donors have specific things they can donate do, as opposed to more vague "this month's MonKon funding stage"
**\<sarang>** s/do/to
**\<suraeNoether>** so what happens if you drum up money by the payment deadline for venue but not A/V? it's a tricky question.
**\<suraeNoether>** i don't pretend to ahve all the answers
**\<suraeNoether>** second source of funding problems: we had 58 general admission tickets, 4 student tickets, 11 platinum tickets, 27 speaker tickets, 13 sponsor tickets, and 3 media passes. our original budget was based on 230 attendees and 20 speakers. So, our ticket sales were disappointing in that regard.
**\<sarang>** Well presumably you would not be the one stuck with all this, and be able to focus more on research or MKon content instead
**\<suraeNoether>** but that was exacerbated since we were paying for flights and hotels for speakers, and the increased size of the speaker list caused increased requisite costs, too
**\<suraeNoether>** thirdly, and most fatally, i think, was the increased cost in A/V
**\<sarang>** Having quality recordings was huge
**\<sarang>** video views were pretty high
**\<suraeNoether>** our original proposal was 1/3 what we ended up paying (and that doesn't count any of the time or labor or equipment donated by parasew, marcvvs, and sgp)
**\<suraeNoether>** ^ bingo
**\<sarang>** And it meant that anyone could watch for free
**\<suraeNoether>** i think the A/V costs from this year is a good benchmark for future years, I don't think we got screwed on A/V, but our costs were very high in this area because of it
**\<sarang>** A/V is expensive, hands down
**\<sarang>** but it seems one of the best returns to the community
**\<suraeNoether>** so, long story short: the market murdered me, the ticket sales murdered me, and A/V murdered me, but i'm still alive despite thrice being murdered
**\<sarang>** you have 6 lives left
**\<suraeNoether>** nah, i was murdered twice already, i'm down to 4
**\<sarang>** Ignoring all the budgeting, I'd say it was a big success
**\<suraeNoether>** I agree. final budget will be posted later this week once i've octuply checked everything.
**\<suraeNoether>** nioc ^ check out our numbers from above. total attendance was like 117 before staff was included
**\<sarang>** that's not half bad for a first run
**\<nioc>** so my quick that totaled up 120 was not bad :)
**\<suraeNoether>** a few brief comments for the four guides i've written: you can do what you like, if you are planning on hosting a Konferenco Wien or a Konferenco Beijing or whatever, do what you like. But make sure all of your funding and structure details are 100% clear in your CCS. Sarang thinks some of my ideas about profit for these events are not fair to the community, so consider the whole set of documents worth
**\<suraeNoether>** arguing over and debating.
**\<nioc>** NYC during blockchain week and MCC will get you 3x
**\<suraeNoether>** nioc yeah, but in terms of \*ticket sales\* we had like 71 or 72 or something like that
**\<suraeNoether>** nioc yeah but it will 4x or 5x all our expenses
**\<dEBRUYNE>** Playing devils advocate, but the funds could've been hedged
**\<dEBRUYNE>** There are plenty of markets that allow short selling of xmr
**\<sarang>** There could have been more defined payouts
**\<sarang>** suraeNoether: anything else to discuss?
**\<sarang>** Or any questions for him?
**\<suraeNoether>** dEBRUYNE: yeah, I received the funds on 2-5-19 and by that point the damage had been done. that would be handled by the CCS guys
**\<suraeNoether>** sarang: defined payouts wouldn't have helped
**\<suraeNoether>** the market crashed basically welllllll before we needed any of the money
**\<sarang>** I see
**\<dEBRUYNE>** At what time was the donation completed though?
**\<dEBRUYNE>** Because at that point the price should've been hedged
**\<suraeNoether>** dEBRUYNE: my recollection is around xmas, but i could be misrecollecting
**\<suraeNoether>** luigi1111 may know
**\<ArticMine>** Yes if the expenses were in USD
**\<suraeNoether>** this question occurred to me yesterday and i forgot to write it down
**\<dEBRUYNE>** Price moved from ~50 to ~70 (from christmas to may), so that doesn't seem right
**\<sarang>** Shall we move on from this topic for now?
**\<suraeNoether>** dEBRUYNE: i had only gains from the time that i was holding crypto. i just received 591 XMR worth $28,509 at the time, whereas when I posted the request it was for 591 XMR worth $60,100. The question is the gap in time between funding-completed and the time it hit the Konferenco wallet on Feb 2
**\<nioc>** there were donations till at least Dec 16
**\<suraeNoether>** i'm fine with waiting for specific dates from luigi or whoever can tell us
**\<suraeNoether>** and moving on
**\<suraeNoether>** sarang, how about you tell us about something more research related?
**\<sarang>** Heh ok
**\<sarang>** I have a few things
**\<luigi1111>** I don't have info on completed funding dates
**\<sarang>** First, I ran a timing/space analysis for the RCT3 sublinear transaction protocol
**\<luigi1111>** not sure if there's a way to get it. surely can manually somehow
**\<sarang>** https://github.com/SarangNoether/skunkworks/blob/sublinear/rct3.md
**\<sarang>** I'm working up some proof-of-concept code for its spend proving system presently (not done)
**\<sarang>** I also worked up a proof of concept for a two-layer Lelantus prover that sacrifices size and verification time for shorter prove time
**\<sarang>** Interesting, but probably not relevant to our use case
**\<luigi1111>** I thought sponsors were going to cover some of the shortfall or something since we knew back then 591 wasn't enough
**\<sarang>** https://github.com/SarangNoether/skunkworks/blob/lelantus/lelantus/layer.py
**\<dEBRUYNE>** suraeNoether: I guess we can discuss this later. One more thing I wanted to ask though, the zcash donation was made in may
**\<dEBRUYNE>** Was that on top of the 28.5k then? Given that you received that earlier
**\<luigi1111>** in truth, ccs isn't particularly well suited for people or projects that are sensitive to volatility. there may be mitigations of course
**\<suraeNoether>** nope, they donated directly to the CCS so that was included
**\<suraeNoether>** luigi1111: the goal was to get corporate sponsorships
**\<suraeNoether>** luigi1111: we got some
**\<suraeNoether>** luigi1111: we did not get enough to cover the shortfall
**\<luigi1111>** I see
**\<luigi1111>** what is the shortfall?
**\<suraeNoether>** sarang sorry to interrupt you: good work on lelantus. have you worked out the tradeoff between our current size vs. verf time compared to a lelantus version with a faster prover?
**\<suraeNoether>** luigi1111: i'll be posting budget later this week
**\<luigi1111>** ok sounds good
**\<sarang>** The faster Lelantus prover makes sense for Zcoin, who want >O(10K) ring members
**\<sarang>** and, to be fair, you can batch away much of the verification loss
**\<sarang>** for O(100-100K) ring members it's likely not really a problem in practice
**\<sarang>** but it's still damn clever
**\<suraeNoether>** i'd be interested in seeing some hard numbers, like the value N such that for >O(N) ring members, the shorter prove time is worthwhile
**\<sarang>** whoops, O(100-1K)
**\<sarang>** define "worthwhile"...
**\<sarang>** all depends on what the max prove time (and the corresponding computational complexity) is that you're willing to accept
**\<suraeNoether>** or how much verf time/space you are willing to sacrifice
**\<sarang>** Zcoin has non-public numbers for this (can't share yet)
**\<suraeNoether>** k
**\<sarang>** However, it's pretty impressive... like, on the order of 10x improvement for large rings (in proving time)
**\<sarang>** I don't think the integration into the rest of the Lelantus prover is completed yet, FWIW
**\<sarang>** there's some info you need to extract from the 1-of-N proof for balance purposes that I haven't worked out
**\<sarang>** On the RCT3 side, this week I should have working code for that transaction protocol
**\<sarang>** I'm checking a bunch of their math (might have errors, not sure yet)
**\<sarang>** and that's about it for me
**\<sarang>** Any particular questions?
**\<ArticMine>** On a more mundane level of mixing I estimate we can move from 11 to 13 without touching fees
**\<sarang>** Based on my CLSAG numbers, you mean?
**\<sarang>** or something else?
**\<ArticMine>** No current tech
**\<sarang>** CLSAG will almost certainly not make it into the fall upgrade
**\<sarang>** How so?
**\<suraeNoether>** ArticMine: i would almost rather increase fees than ring size at this point :\\
**\<ArticMine>** There was a drop in tx size last fork
**\<suraeNoether>** sarang i have a question: fill in the blank to complete the analogy. (lelantus protocol) : (monero protocol) :: (2-year old mid-range automobile with no damage) : \_\_\_\_\_\_\_\_
**\<sarang>** While bigger rings are generally better, a marginal increase from 11 to 13 will do little to help analysis that already exists
**\<sarang>** ...
**\<suraeNoether>** 2-year old mid-range refrigerator with no stink?
**\<sarang>** lol
**\<sarang>** maybe that cleaning car that the Cat in the Hat drives?
**\<sarang>** Looks cool, pretty functional, not sure what'd happen in practice =p
**\<suraeNoether>** how about the weird stretchy-squishy car from Willy Wonka
**\<sarang>** lol
**\<suraeNoether>** wait, has monero switched with lelantus in your analogy?
**\<gingeropolous>** bumpdaringsize
**\<sarang>** erm
**\<suraeNoether>** bumpdaringsize.gif
**\<sarang>** We should determine specific reasons why we would increase
**\<sarang>** e.g. things like chain reaction or accidental dead outputs are exceedingly unlikely now
**\<gingeropolous>** \#1. 13 > 11
**\<sarang>** things like EABCD...ZE are presumably more unaffected by such a marginal change
**\<suraeNoether>** Does anyone have any questions for sarang about his lelantus work recently, other than stupid SAT analogies?
**\<ArticMine>** FloodXMR is very sensitive to ring size
**\<sarang>** (or on RCT3 for that matter)
**\<sarang>** Yes, but we don't have correct numbers on that yet
**\<sarang>** in terms of cost, that is
**\<sarang>** It should be quantified before a blind increase, IMO
**\<suraeNoether>** okay, everyone: i have to get to an appointment
**\<sarang>** roger
**\<suraeNoether>** remember, for the hypochondriacs: if the pain is behind and above your stomach, it could be pancreatitis and not a heart attack
**\<ArticMine>** Ok we wait for CLSAG and then take another look at mixin
**\<sarang>** I'm not saying we have to wait until spring
**\<sarang>** only that I'd prefer quantified reasons for an increase to know the benefits
**\<sarang>** Increasing from 11 to 13 won't stop a wealthy adversary from chain spamming with the current fee structure
**\<sarang>** knowing the added protection against deanon would be useful though
**\<sarang>** sgp\_ has a useful little tool for this
**\<sarang>** I'll grab numbers for that part at least (the flood folks are running new simulations on a private testnet)
**\<sarang>** OK, does anyone else have work to share?
**\<sarang>** Or other updates relevant to this channel?
**\<sarang>** If not, we can leave the floor open to QUESTIONS while we go over ACTION ITEMS (to respect the time)
**\<sarang>** I'll grab numbers on an 11 -> 13 ring increase, finish up RCT3 proof-of-concept stuff, and continue defcon prep
**\<sarang>** suraeNoether can update us later when he returns
**\<sarang>** Any last questions or comments before we adjourn?
**\<midipoet>** i have read over konferenco talk, and have taken notes of the links...will digest. thanks suraeNoether
**\<sarang>** OK, we are now adjourned! Thanks to everyone for joining in
**\<sarang>** Logs will be posted to the github agenda issue shortly

194
_posts/2019-07-18-logs-for-the-tini2p-dev-meeting-held-on-2019-07-18.md Normal file
View file

@ -0,0 +1,194 @@
---
layout: post
title: Overview and Logs for the tini2p Dev Meeting Held on 2019-07-18
summary: Current project status, Roadmap, Meta issues, and miscellaneous
tags: [dev diaries, i2p, crypto]
author: el00ruobuob / oneiric
---
# Logs
**tini2p** 0: Greetings
hi
1: What's been done
Not a lot code-wise, spent quite a bit of time working on spec proposals
zzz made some updates to 144 examples, and my suggestions for a NewSessionReply are being reviewed
as of today, here is a diff with my suggestions: https://gitlab.com/snippets/1876476
**David Burkett**
**tini2p** hi
**David Burkett** Don't mind me. Just listening in and hoping to learn something :)
**tini2p** :) right on, glad to have you here
feel free to ask questions or make comments on anything
**David Burkett**
**tini2p** here are my latest updates to the ECIES Tunnels draft proposal: https://geti2p.net/spec/proposals/152-ecies-tunnels
got some feedback from zzz today, so will make a couple more additions
will more or less be moving forward with the changes in the 144 diffs, and the 152 draft
will hopefully have something working by next Thursday
then alpha release
the release will be a bit ugly (code-wise), and will likely change quite a bit between alpha and beta release
but the core functionality will be in place, and at the least building end-to-end sessions will be possible through tini2p routers
**David Burkett** That's excellent!
**tini2p** it is NOT recommended to build connections on live networks, or contexts that require strong privacy
given that tini2p is in the earliest stages, there are likely bugs, and there will be very few routers running tini2p
**David Burkett** Will close my PR to bitcoin core and await further maturation :)
**tini2p** :)
what do you mean? use it for all the things :P in all seriousness it still needs a lot of work before recommending use to other projects
**David Burkett** just trolling lol
**tini2p** if I get interop working with ElGamal tunnels working, technically it would be possible to build tunnels through existing I2P routers
I will add a test network netid to prevent interaction with the live network by default
**David Burkett** That's what I'm looking forward to...I think. So many protocols, it's a lot to wrap my head around
**tini2p** so, it means you could build outbound and inbound tunnels using existing I2P routers as intermediary hops
the ends of the end-to-end session would still need to be tini2p routers, until we get 144 fully fleshed out
i.e. you won't be able to connect to existing I2P destinations
**David Burkett** Still fine with me. So the "tunnels" would be the same protocol as existing destinations, but the "sessions" would be a different protocol?
Or am I wildly incorrect
**tini2p** even the interop with existing I2P routers as tunnel hops is a maybe, and remains to be tested
so lets take the situation where router A wants to talk to router B
router A builds and outbound tunnel with outbound endpoint of OA
router b builds an inbound tunnel with inbound gateway IB
A and B will need to be tini2p routers
**David Burkett** G
got it
**tini2p** the routers between A and OA, and B and IB can be tini2p or existing I2P/i2pd routers
OA and IB can be tini2p/I2P/i2pd as well
that's the goal anyway, integration and end-to-end tests on a test network still need to be done
that's why I'll be adding a test network netid to prevent interacting with the live I2P mainnet by default
**David Burkett** So if a p2p project decided to use tini2p, it could only communicate with other peers running i2p, but theoretically, it would get the anonymity set of the i2p network as a whole, correct?
**tini2p** it will require the user to change the code and recompile
if I can get tunnel interop working it would be able to use the existing anonymity set for tunnel building
**David Burkett** :thumbsup: Understood
**tini2p** however, it may still be possible to detect tini2p destinations, so may still have a limited anonymity set in that way
for full tini2p stealth mode, it would require using blinded leaseset2 published to netdb
I haven't implemented blinded leaseset2, and they aren't live for I2P or i2pd yet either
**David Burkett** I don't necessarily need to hide participation, so that would be fine. But it would be difficult to detect which participants are communicating with each other, correct?
**tini2p** though I think i2pd has made a ton of progress there
tini2p hop participants in tunnels should look like any other I2P hop to existing non-tini2p routers
**David Burkett** excellent
**tini2p** they will be distinguishable to tini2p tunnel creators
that should change if 152 is adopted network wide, but that is still a long way off
we're still in the earliest stages of discussing 152
long way from seeing implementation and adoption by other implementations
if it is at all
**David Burkett** Ah, using the context I just gained from this discussion, I now at least understand what's being proposed in 144 & 152. So thanks!
**tini2p** awesome, happy to help!
144 is closer to adoption, and when the spec is finalized, tini2p will be able to connect to any destination implementing the spec
zzz has longer estimates than I do for finalization though, so TBD
152 might get split into two proposals, one for tunnel building changes, one for tunnel layer encryption
there appear to be less concerns with tunnel building, and the changes for tunnel layer encryption introduce Blowfish as a new crypto primitive for nonce encryption
**tini2p** tini2p and ECIES routers need the tunnel building changes to build through existing I2P ElGamal routers, but can use existing tunnel layer encryption for passing/encrypting messages to existing tunnel participants
e.g. there is no way for an ECIES identity to encrypt to an ElGamal identity (no X25519-ElGamal key exchange algo exists)
**David Burkett** Why Blowfish?
**tini2p** how 152 proposes solving this is using an ElGamal identity to encrypt build records to existing ElGamal hops, and an ECIES identity for ECIES hops
Blowfish is a 64-bit block symmetric cipher, which is normally a bad idea with new protocols
**David Burkett** So 152 == Prefer ECIES, but support both for interoperability?
**tini2p** however, it is only used to encrypt nonces used for ChaCha20 tunnel layer encryption
re: interop, mostly yes. though at first, ElGamal will be preferred in practicality, given they are the entirety of the available hops atm
**David Burkett** And if a single nonce is compromised, ChaCha20 still remains relatively secure compared to other stream ciphers. So that makes sense
**tini2p** the only existing practical attack against Blowfish is the Sweet32 birthday attack, which gets block collision in ~2^32 blocks
yeah if the nonce gets compromised, it doesn't affect the ChaCha20 encryption
**David Burkett** O, then why does Schneier discourage it? Just because it's only 64 bytes?
\*bits :)
**tini2p** nonce compromise does allow two non-consecutive tunnel hops to know they are in the same tunnel, which has some consequences for I2P
64-bit block ciphers are not as good as 128-bit+ block ciphers when using it for full confidentiality, yeah
**David Burkett** Gotcha, I think I've seen him recommend threefish over blowfish before, even though both are 64-bit. O well, I digress. Carry on
**tini2p** in this case though, we need Blowfish for it's 64-bit block size because ChaCha20 only has a max of 96-bit nonces
(in the ietf version)
threefish is 64-bit?
if so, I'll change it to threefish
**David Burkett** I believe, let me check
**tini2p** the 64-bit block is what's important, so if there is a stronger algo supporting 64-bit block size, I'll use that
**David Burkett** https://en.wikipedia.org/wiki/Threefish
Looks like it
**tini2p** :rocket: so nice, thank you!!!
honestly preferred something stronger than Blowfish, so will look into threefish, and it's support in crypto libs
**David Burkett** Please confirm though. When it comes to crypto, all 'facts' come straight from my backside.
**tini2p** sure, I will investigate
**David Burkett**
**tini2p** While nonce compromise doesn't destroy the crypto system, it does leak info to attackers that could enable strong attacks between non-consecutive tunnel hops
**David Burkett** Makes sense
**tini2p** i.e. if E -> H -> G are tunnel hops, and E + G are colluding attackers, compromising H's nonce would allow E + G to know they are in the same tunnel
it doesn't fully destroy the anonymity of using tunnel proxies, but severely compromises it
so want to protect against it as much as possible
why I set the limit of tunnel messages to 2^31, so that Sweet32 attacks against Blowfish aren't possible
though even 2^30 messages will never be practically reached in 10 minute tunnels
it's on the order of millions of messages per second
existing tunnel layer encryption uses double encryption with AES256/ECB for tunnel IVs to defeat the described confirmation attack
duplicate IVs are also rejected, further protecting against the attack
going to run some tests on that, but makes sense atm
**tini2p** i.e. see if observable patterns can be detected in IVs that only change a bit or two
if they can, then the changes for tunnel layer encryption become much more important
**David Burkett** There shouldn't be any observable patterns. If changing 1 bit is in any way detectable, the cipher failed
**tini2p** my hypothesis going into it though is that they can't
right
ECB has its problems, but hopefully it isn't that broken
2: What's next
we basically just covered what I'll be working on over the next week
goal is to get an ECIES impl in place following the 144 diffs, work on solidifying the 152 proposal, and getting a tunnel impl in place
**tini2p** it may only be possible to do ECIES-to-ECIES tunnels by next Thursday, but sometimes miraculous things happen :)
**David Burkett** Indeed. Good luck!
**tini2p** thanks
3: Comments / Questions
4: Next Meeting
2019-07-25 18:00 UTC
will be discussing alpha release, and then resuming 2-week meeting schedule
meeting over!
**David Burkett** Thanks @tini2p\_gitlab!
@tini2p\_gitlab bangs a squeaky toy gavel
**tini2p** thanks for attending!

196
_posts/2019-07-20-logs-for-the-Community-meeting-held-on-2019-07-20.md Normal file
View file

@ -0,0 +1,196 @@
---
layout: post
title: Logs for the Community Meeting Held on 2019-07-20
summary: Community highlights, CCS updates, Workgroup report, and miscellaneous
tags: [community, crypto]
author: el00ruobuob / rehrar
---
# Logs
**\<sgp\_>** community meeting starting now
**\<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/374
**\<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
**\<rottensox>** o/
**\<ArticMine>** hi
**\<el00ruobuob\_[m]>** Hi
**\<sarang>** Hi
**\<rehrar>** oyo boyo
**\<xmrscott[m]>** Yo yo yk
**\<kinghat>** hey
**\<rehrar>** Yo yo yk
**\<parasew[m]>** hello!
**\<sgp\_>** 2. Community highlights
**\<sgp\_>** See Monero weekly highlights at https://revuo-monero.com/
**\<sgp\_>** rehrar put me out of a job :)
**\<sgp\_>** Does anyone else have community (non-workgroup) updates to share?
**\<sgp\_>** 3. CCS updates
**\<sgp\_>** CCS proposals in ideas to be discussed (one by one):
**\<sgp\_>** “v1docq47: video creation / translations into russian (august – january)” (37.8 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/84
**\<rehrar>** sure
**\<sgp\_>** lh1008 indicated support on Gitlab, I also support
**\<el00ruobuob\_[m]>** v1docq47 seems to have done a huge amount of work on his previous FFS, i vote for.
**\<msvb-mob>** Hello.
**\<sgp\_>** any other comments?
**\<rehrar>** ne
**\<pwrcycle>** I just read the FSS, but seems good to me. I vote yes.
**\<sgp\_>** great
**\<sgp\_>** second one: “A Monero Tip Bot for Telegram” (13 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/86
**\<rehrar>** he updated prices
**\<rehrar>** seems more reasonable now
**\<rehrar>** I say sure
**\<jwinterm>** aren't there already a bunch of telegram tipping bots available?
**\<jwinterm>** $1k for forking a repo and running bot seem kinda pricey to me
**\<jwinterm>** but my dumbass does it for free
**\<parasew[m]>** is this the tipping bot which is at use in the monero-germany tg group?
**\<el00ruobuob\_[m]>** i didn't see he updated price. For 13XMR, sounds good to me
**\<pwrcycle>** I don't see the use in a app specifit, channel specific bot. And I think there are other bots that can do this already.
**\<pwrcycle>** FFS says: "This bot is the first of its kind..." I do not agree with that.
**\<el00ruobuob\_[m]>** wait, there is a tg tipping bot on monero-germany parasew[m]?
**\<rehrar>** I seem to remmber there was one one day
**\<rehrar>** but if there is one that exists, please comment with that one there
**\<pwrcycle>** If the Tip bot is so good, why not just build it and have people tip you for it? Why a FSS?
**\<parasew[m]>** el00ruobuob\_[m]: yes there is one, but testnet only
**\<pwrcycle>** I vote no on the tip bot.
**\<el00ruobuob\_[m]>** it should be easy to just update the existing one then...
**\<parasew[m]>** this is the tipbot on monero germany: https://imgur.com/a/S7k3oa2
**\<rehrar>** parasew[m]: where is the repo?
**\<parasew[m]>** not sure where repo is, i just remembered the bot there; let me search for more info
**\<rehrar>** thx
**\<el00ruobuob\_[m]>** not reinventing the wheel could be great here. If there is a bot already, i don't see the benefit of a new one.
**\<rehrar>** yep
**\<xmrscott[m]>** Agreed, work smarter, not harder as they say
**\<rehrar>** so the prereq of my support is no good bot existing
**\<rehrar>** next?
**\<sgp\_>** any final comments? seems like this is a reasonable question to address first
**\<parasew[m]>** bot might be the same that is the one of the CCS in question. i asked in monero germany tg
**\<sgp\_>** please comment on gitlab when you get more info
**\<sgp\_>** third idea: “rehrar-sarang WCC” (30 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/87
**\<parasew[m]>** yes sure
**\<rehrar>** I vote yes
**\<rehrar>** er
**\<rehrar>** I mean
**\<rehrar>** I recuse myself
**\<sarang>** I abstain from a "vote" on this, obviously
**\<el00ruobuob\_[m]>** are you confident with a 10% buffer at the moment?
**\<msvb-mob>** I like the IRC tippero a lot, this is a nice idea.
**\<el00ruobuob\_[m]>** i see price raise and fall like of 20% those days...
**\<rehrar>** dude the market is def much more valite than normal
**\<rehrar>** we can maybe do 15%?
**\<rehrar>** but that's a bit much
**\<sarang>** Excess to general fund?
**\<sarang>** (if there is any)
**\<el00ruobuob\_[m]>** it's your call, i just found market so volatile...
**\<rehrar>** we can do that
**\<sarang>** Then perhaps a higher margin would be acceptable
**\<pwrcycle>** sarang's talks are really good. rehrar is really personalable at big events and really knowledgable. I vote yes on WCC.
**\<sarang>** (provided this is all specified on the CCS)
**\<sarang>** thanks pwrcycle
**\<parasew[m]>** i second
**\<el00ruobuob\_[m]>** btw, i am sure for it. You two are great speakers
**\<sarang>** rehrar: I assume you would not be the one to merge this particular CCS?
**\<sarang>** Should be done by someone else for better transparency
**\<rehrar>** sure
**\<rehrar>** I never merge
**\<rehrar>** luigi does
**\<sarang>** oh nvm
**\<sarang>** thought you also did
**\<sgp\_>** any final comments on this one?
**\<Inge->** +1 on WCC
**\<sgp\_>** 4. Workgroup report
**\<sgp\_>** a. Daemon/CLI workgroup
**\<sgp\_>** 0.14.1.2 is tagged now I believe
**\<sgp\_>** I'm out of the loop on the difference between 0.14.1.1 and 0.14.1.2
**\<selsta>** v0.14.1.1 had problems with checkpoints
**\<selsta>** We forgot to change a file.
**\<sgp\_>** selsta: thanks
**\<sgp\_>** any other recent developments you think are worth mentioning?
**\<selsta>** difference between v0.14.1.0 and v0.14.1.2 is mostly bug fixes
**\<sgp\_>** thanks
**\<sgp\_>** b. Localization workgroup
**\<sgp\_>** Is ErCiccione[m] here to give an update?
**\<sgp\_>** or anyone else with a comment
**\<sgp\_>** all right, nothing to report
**\<sgp\_>** c. GUI workgroup
**\<sgp\_>** dsc\_: want to discuss some of the recent work you have done?
**\<sgp\_>** there was recent work on better TAILS support, and up next is i2p-zero integration
**\<sgp\_>** there have been quite a few other UI changes
**\<sgp\_>** better account support, better balance card, etc
**\<sgp\_>** any GUI questions? I may be able to answer them
**\<selsta>** better balance card is work in progress
**\<sgp\_>** https://github.com/monero-project/monero-gui/issues/2298
**\<selsta>** v0.14.1.2 GUI will also come out soon after CLI.
**\<ArticMine>** One question is ow fees are displayed
**\<sgp\_>** selsta: will there be any UX changes, or just bundled with the latest daemon?
**\<ArticMine>** how
**\<ArticMine>** The fee levels do not correspond to the actual fees
**\<selsta>** sgp\_: Bug fixes and minor UX changes.
**\<hahsun>** hi everyone
**\<sgp\_>** ArticMine: I do not know the answer to this, probably best to ask in #monero-gui
**\<sgp\_>** hello hahsun
**\<hahsun>** did I miss the meeting?
**\<sgp\_>** no, still ongoing
**\<hahsun>** cool :)
**\<sgp\_>** any GUI questions or updates?
**\<sgp\_>** d. Defcon workgroup
**\<sgp\_>** We just had the meeting before this, so I won’t say much more here other than to say all the final preparations are being made now. Please go to #monero-defcon if you want to help out.
**\<sgp\_>** Direct all questions there please :)
**\<sgp\_>** Well, we powered through the agenda and are left with 5. Open ideas time
**\<sgp\_>** It’s open ideas time! Feel free to propose your ideas to this discussion group, and feel free to comment on others’ ideas. If you disagree with the idea, please reply with constructive criticism. Thank you!
**\<sgp\_>** I know many people are busy with Defcon planning right now, but what can the community workgroup do better?
**\<hahsun>** if I missed the questions on the proposal 86 please feel free to ask. I am here now.
**\<sgp\_>** hahsun: yes, there were a few questions
**\<hahsun>** unfortunately I have no logs. just joined.
**\<sgp\_>** someone mentioned the @MoneroTipBot existing Telegram bot and wanted to confirm that it wouldn't be redundant
**\<sarang>** (it's not on the agenda but I'm also happy to answer any relevant MRL questions during workgroup Q&A)
**\<hahsun>** sgp\_: no it is not redundant. I can confirm.
**\<sgp\_>** parasew[m] rehrar pwrcycle jwinterm el00ruobuob\_[m] xmrscott[m] had comments before, any questions?
**\<pwrcycle>** hahsun: FFS says: "This bot is the first of its kind..." but there seem to be many other tip bots and Telegram bots.
**\<el00ruobuob\_[m]>** How is it not redundant with the one mentioned by parasew[m] https://imgur.com/a/S7k3oa2 ?
**\<msvb-mob>** No questions from me, thanks.
**\<hahsun>** pwrcycle: no there is only one.
**\<hahsun>** el00ruobuob\_[m]: that bot you see on the picture is the bot we are testing in the monero telegram groups
**\<dEBRUYNE>** el00ruobuob\_[m]: Do you intend to work on the meeting logs btw? I think the last one on the website is from mid june
**\<hahsun>** I can confirm that the bot is not redundant. because the very mentioned @MoneroTipBot IS the bot of the proposal.
**\<el00ruobuob\_[m]>** ok, so this is the bot you're going to implement on mainnet?
**\<hahsun>** exactly
**\<el00ruobuob\_[m]>** dEBRUYNE, yes, i've been busy on other things, and have to catch back. Will do it soon, i swear
**\<dEBRUYNE>** All right, thanks
**\<pwrcycle>** How would funds tipped from one user to another be handled? Is the bot wallet in custody of XMR during tipping?
**\<hahsun>** we are currently testing the bot in various groups with the help of many people to be able to deliver the bot on time. it is very alpha stage right now and bug fixing is ongoing.
**\<el00ruobuob\_[m]>** thanks hahsun, so i'm back on my "ok for me" opinion then
**\<hahsun>** pwrcycle: the bot wallet is a monero-wallet-rpc daemon running with the wallet file open on a VPS.
**\<hahsun>** the goal is to get a trusted member of the core team to host this wallet file.
**\<hahsun>** I asked mooo and he denied. and am now in contact with fluffy to see if it can be run side by side with the IRC tip bot.
**\<pwrcycle>** I don't like that part. Having someone in the middle seems risky.
**\<hahsun>** pwrcycle: it was the best compromise I could think of in this case. this is a custodial bot.
**\<hahsun>** and to seek trust, we came up with the idea to let it run by a trusted member.
**\<pwrcycle>** did the IRC tip bot get a FSS? I don't see how funding something on a private app, for users already, basically into Monero because they are in the channel. So I don't see how the tip bot expands the community.
**\<hahsun>** pwrcycle: I cant comment on the IRC tipbot but I estimate to reach approx. 10k users in telegram in the effort to bring monero closer to the people.
**\<pwrcycle>** I mean, the bot would be cool. And bots in channels are useful. but for the project to fund a bot for one app, why not fund bots for them all, and do bots really bring more people in and connected to the privacy aspect of the project.
**\<pwrcycle>** IRC is where the main project is held and many other FOSS projects, so a bot there would make sense.
**\<hahsun>** pwrcycle: as far as I can tell by now, the bot is a funny way to get together with other people. discussions on various other monero related topics rise through the interaction with the bot.
**\<pwrcycle>** But still, I don't think it was funded, it was just doned.
**\<pwrcycle>** \*donated.
**\<hahsun>** pwrcycle: afaik the irc tipbot was a fluffy/mooo project. but I dont know much about it other than that.
**\<sgp\_>** fwiw, many other crypto communities are on Telegram and Discord
**\<pwrcycle>** Let those communities fund the bot. If the Tip bot entertains the Telegram channel, let the Telegram channel Tip for it's creation.
**\<hahsun>** also, on telegram, is the church of monero. where people hold masses to exchange small amounts of monero. this teaches people to learn the GUI wallet for example.
**\<sgp\_>** pwrcycle: the CCS isn't necessarily "IRC community only"
**\<sgp\_>** we are over time, and I'm glad we were able to ask some questions and have some answered. Discussions on this CCS can continue here and on Gitlab
**\<sgp\_>** I'm going to conclude the meeting
**\<sgp\_>** 6. Confirm next meeting date/time
**\<sgp\_>** The next community meeting will be in 2 weeks on 3 August at 17:00 UTC. The next Coffee Chat will be on 27 July at 16 UTC. I will not be present at this event.
**\<sgp\_>** 7. Conclusion
**\<sgp\_>** That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.
**\<hahsun>** thank you all for your questions.
**\<pwrcycle>** o7
**\<el00ruobuob\_[m]>** Bye§
**\<jwinterm>** pwrcycle, afaik moneromooo wasn't ffs for tippero
**\<selsta>** There’s a Monero Austria meetup on August 1st at Riat, https://www.meetup.com/Monero-Austria/events/263317607/
**\<sgp\_>** ty selsta
**\<selsta>** topics include deep dive into DLSAG