4rkal/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-12-04 23:51:11 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

Meeting logs for October

Browse Source
This commit is contained in:
el00ruobuob 2019-10-26 20:09:26 +02:00
parent 75adcbd428
commit b6fff2cb37
No known key found for this signature in database
GPG Key ID: 8794A50E11FE51A0
9 changed files with 1172 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
_posts/2019-10-03-logs-for-the-tini2p-dev-meeting-held-on-2019-10-03.md Normal file
View File

@ -0,0 +1,48 @@
---
layout: post
title: Overview and Logs for the tini2p Dev Meeting Held on 2019-10-03
summary: Current project status, Roadmap, Meta issues, and miscellaneous
tags: [dev diaries, i2p, crypto]
author: el00ruobuob / oneiric
---
# Logs
**\<tini2p\_gitlab>** meet time
**\<tini2p\_gitlab>** 0: Greetings
**\<tini2p\_gitlab>** hi all
**\<tini2p\_gitlab>** 1: What's been done
**\<tini2p\_gitlab>** an incredible amount of refactoring, and router context impl
**\<tini2p\_gitlab>** a lot of the early code that I wrote in the first months of the project has returned to bite me
**\<tini2p\_gitlab>** I've spent a good amount of time correcting early design and implementation mistakes
**\<tini2p\_gitlab>** work remains on the refactoring front, but it works
**\<tini2p\_gitlab>** the real test will come with cross-implementation integration tests (post-alpha)
**\<tini2p\_gitlab>** you can see my progress in the `context` branch: https://gitlab.com/tini2p/tini2p/tree/context
**\<tini2p\_gitlab>** I have a bit more work to do cleaning things up, and making the context work without so much manual interaction
**\<tini2p\_gitlab>** but tunnel messages, and end-to-end ECIES messaging works over localhost!
**\<tini2p\_gitlab>** you can see for yourself here: https://gitlab.com/tini2p/tini2p/blob/context/tests/net\_tests/router/context.cc
**\<tini2p\_gitlab>** notably, this test shows an end-to-end ECIES session over inbound and outbound tunnels: https://gitlab.com/tini2p/tini2p/blob/context/tests/net\_tests/router/context.cc#L402
**\<tini2p\_gitlab>** you can also see that I'm manually adding tunnels, selecting which router infos are used for tunnel hops, and manually creating the LeaseSet
**\<tini2p\_gitlab>** so all that needs to be automated, and wrapped in functions inside the router context itself
**\<tini2p\_gitlab>** I'll be working on that for the remainder of today, and pushing an alpha release candidate today or tomorrow
**\<tini2p\_gitlab>** I'll leave the alpha candidate open for review for one week before merging into master
**\<tini2p\_gitlab>** I've also updated my ECIES impl to \*mostly\* match what is in the current revision of [144](https://geti2p.net/spec/proposals/144-ecies-x25519-aead-ratchet)
**\<tini2p\_gitlab>** where there are TODOs and otherwise murky content, I've filled in the gaps
**\<tini2p\_gitlab>** the proposal is still highly in flux, and I will continue to update my impl until we reach a stable spec
**\<tini2p\_gitlab>** over the last few meetings, zzz, orignal, the rest of the I2P devs, and I have been making a lot of progress
**\<tini2p\_gitlab>** zzz is dedicating time to the next I2P release, and will return focus to 144 afterward
**\<tini2p\_gitlab>** they have stated an estimate for end-of-year for a stable spec/rollout in Java I2P impl code
**\<tini2p\_gitlab>** I'm hoping to also be ready with some client code (I2CP, SAMv3, Reseed) around that time to do full integration tests with Java I2P and i2pd
**\<tini2p\_gitlab>** (ire too if str4d is ready :)
**\<tini2p\_gitlab>** after alpha, I'll also be implementing ElGamal tunnel building, so that tini2p users will be able to build tunnels through existing Java I2P and i2pd routers
**\<tini2p\_gitlab>** after that, Reseed
**\<tini2p\_gitlab>** between now and next week, I'll be working on more bug fixes, the automation of router context stuffs, and trying to put together instructions for running tini2p routers over a docker testnet
**\<tini2p\_gitlab>** docker testnet may wait until after alpha release, since I have net-tests that show full end-to-end communication (even if it is only over localhost)
**\<tini2p\_gitlab>** that was 2: What's next
**\<tini2p\_gitlab>** :0
**\<tini2p\_gitlab>** 3: Comments / questions
**\<tini2p\_gitlab>** then that leaves
**\<tini2p\_gitlab>** 4: Next meeting
**\<tini2p\_gitlab>** will be a short update next week for alpha release: 2019-10-10 18:00 UTC
**\<tini2p\_gitlab>** thanks for reading
**\<tini2p\_gitlab>** @tini2p\_gitlab kick juggles the gaffer like a hacky-sack

258
_posts/2019-10-07-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-10-07.md Normal file
View File

@ -0,0 +1,258 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-10-07
summary: Surae work, Sarang work, and miscellaneous
tags: [dev diaries, community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** GREETINGS
**\<suraeNoether>** howdy!
**\<ArticMine>** hi
**\<sarang>** I suppose we can jump into ROUNDTABLE discussion
**\<sarang>** suraeNoether: ?
**\<suraeNoether>** sure; I've been working on my matching code. I fixed a few bad unit tests, i fixed a problem that was making the code take O(n^2) time and now it takes O(n) time... the challenger code and the parameter space explorer code are nearing completion, and my simulations are still misbehaving
**\<sarang>** Any ideas what exactly is misbehaving?
**\<suraeNoether>** i'm also beginning to read about an idea by randomrun and thinkinga bout security proofs for it
**\<suraeNoether>** well, no, that's what's strange. i have unit tests that check things like "check that the correct number of nodes are added to the graph", and they all pass those things... but then the integrated simulation as a whole produces a bad output file
**\<suraeNoether>** which is why i posted the stupid gif the other day of "two unit tests, no integration test"
**\<sarang>** I see
**\<suraeNoether>** but i'm working on it, and i have a few clues... and six more unit tests i'm coding up this afternoon
**\<sarang>** excellent
**\<suraeNoether>** i also want to bring up the topics that isthmus posted on github
**\<sarang>** Let's save those until he returns
**\<suraeNoether>** but we should hold off till the end of the meeting to chat about those
**\<suraeNoether>** \*nod\* he may not return, though, and we should chat about it in public today eventually either way
**\<sarang>** I've worked on a few things this past week
**\<sarang>** I collaborated with Aram on a Lelantus update: https://lelantus.io/enabling-untraceable-anonymous-payments.pdf
**\<sarang>** It seems to solve the sender tracing issue, but at the cost of proper one-time addressing
**\<suraeNoether>** hmm \*taps chin\*
**\<sarang>** Trying to fix both at the same time keeps running into a wall involving Pedersen generators
**\<suraeNoether>** i'm very interested to spend some time catching up on that trade-off
**\<sarang>** So we're looking at possible ways to use Schnorr representation proof tricks here... nothing so far though
**\<sarang>** Aside from that, I updated the RCT3 proof-of-concept code and spacetime analysis to reflect the new version of the preprint that was released
**\<sarang>** They compress the spend proof across inputs, but this incurs some major cost in padding inputs
**\<sarang>** Unfortunately, undoing that compression doesn't play nicely with their integrated balance proof
**\<sarang>** As in, (number of spends)\*(size of anonymity set) must be a power of 2, or padded to one
**\<suraeNoether>** iirc lelantus originally used a tree structure, yeah? is that why?
**\<sarang>** Is what why?
**\<suraeNoether>** is that why they require padding inputs to powers of two?
**\<sarang>** RCT3, not Lelantus
**\<sarang>** It has to do with the inner-product argument that it uses for compression
**\<suraeNoether>** gack, got them confused~ nevermind, i retract my question
**\<suraeNoether>** ah, that makes sense too
**\<sarang>** It would be nice to get separate spend proofs if only to avoid this padding issue
**\<sarang>** but that would require redoing security proofs etc.
**\<sarang>** Finally, I've been working more on some ideas RandomRun had for Triptych involving balance proofs and multiple spends
**\<sarang>** I have a simple version of the Groth proving system that supports proving knowledge of multiple commitment openings to zero, along with linking
**\<sarang>** but haven't done any security proofs (in particular, I have some questions about the uniqueness requirements on certain proof elements)
**\<sarang>** Getting balance integrated is tricky, and that's what I'm working on now
**\<suraeNoether>** is there any write-up anywhere you and/or RR are willing to share with the public, or is this still too much "in prep"?
**\<sarang>** His ideas are listed in the GitHub issue here: https://github.com/monero-project/research-lab/issues/56
**\<sarang>** and the work-in-progress code is here, but very unfinished: https://github.com/SarangNoether/skunkworks/tree/lrs/lrs
**\<suraeNoether>** gotcha
**\<sarang>** and very probably insecure as written
**\<sarang>** Right now it's just at the playing-around-with-the-algebra stage, to see what's useful/possible
**\<suraeNoether>** it's good to clarify that before some other coin goes and implements it :P
**\<sarang>** Anyway, kudos to RandomRun on some really clever ideas to extend that Groth proving system
**\<sarang>** TBH it's probably worth a short paper on its own
**\<sarang>** Right now (if proven secure, mind you) it turns Groth's idea for a ring signature into a linkable ring signature
**\<sarang>** If the balance proof extension works, then we're really cooking
**\<sarang>** Efficiency TBD
**\<sarang>** While we wait for Isthmus to return, I can wrap up by saying my ACTION ITEMS for the week are trying to get balances working in Triptych, finishing a presentation on transaction protocols, and getting caught up on some lit review
**\<suraeNoether>** good timing bruh
**\<sarang>** Isthmus: we didn't talk about your items at all
**\<sarang>** Care to go over them now?
**\<Isthmus>** Sure
**\<Isthmus>** One of the things I've been pondering about is how to assess the appropriate (safe) lock time
**\<Isthmus>** Here is one possible framework for the conversation: https://github.com/noncesense-research-lab/lock\_time\_framework/blob/master/writeup/lock\_time\_framework.pdf
**\<Isthmus>** Since the lock time only needs to be longer than reorg events, we can approach the question systematically by enumerating the list of things that cause alternative blocks, assessing the maximum plausible length of alternative chains that they could produce, and buffer that with a safety term
**\<sarang>** Enumerating the expected sources of reorganizations is a good idea, now that you have some empirical data on latency-based reorgs
**\<Isthmus>** My goal is to take the conversation out of the realm of intuition, towards addressing specific things that we can model/discuss/etc. :- )
**\<sarang>** I seem to recall some talk a long while ago about individual nodes that had observed much longer reorgs, but I assume these were not global?
**\<sarang>** (for some definition of global)
**\<Isthmus>** Well, that was back when there were ASICs on the network
**\<suraeNoether>** i'm inclined toward T2 or T3. the selection of an enforced lock time to ban inarguably-too-short txn times is easy and has an immediate benefit to the system. analysis paralysis while selecting an "optimal" lock time isn't desirable, and having the enforced lock time in place - even if we don't change the current lock time - is critically important
**\<Isthmus>** Yeah, (should we enforce lock time?) and (how long should lock time be?) are two distinct questions
**\<suraeNoether>** so, here's the deal
**\<sarang>** There seemed to be good support for consensus enforcement of whatever value is chosen
**\<sgp\_>** Is it worth exploring privacy implications as well? It could be that the longer the lock time, the better it is for network privacy to some extent
**\<suraeNoether>** sgp\_: this is especially true if the lock time is longer than the median spend-time
**\<suraeNoether>** but that's not a desirable lock time
**\<suraeNoether>** for obvious reasons
**\<suraeNoether>** so, the deal i'm thinking is that it's easy to discern what is \*unacceptably long\* or short in lock times
**\<suraeNoether>** a lock time of two blocks is too short, a lock time of 90 days is too long, for sure
**\<sgp\_>** I don't think it needs to be the main topic (chain re-orgs are more important imo), but it's worth considering
**\<sgp\_>** I think we will have a tough time reducing it from 10 honestly for UX reasons
**\<suraeNoether>** i guess my question is
**\<suraeNoether>** does anyone have an argument in favor of using a value \*other than 10\*
**\<sgp\_>** \*tough time increasing it
**\<sgp\_>** suraeNoether: I would like to justify a smaller number for UX reasons if possible
**\<suraeNoether>** i wouldn't dare lower it further than 10
**\<sgp\_>** Isthmus's document outlines a basic framework for coming up with a number
**\<sgp\_>** suraeNoether: based on what though?
**\<suraeNoether>** or let me rephrase that, because "i wouldn't dare" is a bit dramatic
**\<suraeNoether>** sgp\_: well, we've witnessed many re-orgs length longer than 10. they are downright \*common\*
**\<suraeNoether>** moreover, spend-times that are lower than 20 minutes are \*extremely\* noticable in a txn graph
**\<suraeNoether>** if a sequence of very fast chained txns occur in a row, you can almost bet your ass that they're the same person churning.
**\<ArticMine>** The question in my mind is what is an acceptable risk probability for T2, and T3
**\<suraeNoether>** ArticMine: that was the question that popped into my mind
**\<sgp\_>** that's what I was referring to from the privacy angle
**\<suraeNoether>** \*nod\*
**\<sarang>** Do you happen to know the corresponding threshold for Bitcoin's choice of typical lock time?
**\<sarang>** I don't, off the top of my head
**\<suraeNoether>** ^ sgp\_ or ArticMine or isthmus?
**\<sgp\_>** nope
**\<suraeNoether>** hm
**\<Isthmus>** I'm avoiding commenting on any particular numbers until we decide on a framework for discussing
**\<suraeNoether>** personally i would find it helpful to have those numbers in deciding the framework
**\<sarang>** Here's a writeup that I'd seen before: https://bitcoil.co.il/Doublespend.pdf
**\<dEBRUYNE>** sarang: Bitcoin has no lock time for normal transactions
**\<dEBRUYNE>** You can essentially chain unconfirmed transactions
**\<suraeNoether>** dEBRUYNE: thanks that's important to know, too. :P
**\<sarang>** Page 8 shows some example data based on hashrate and confirmations using Bitcoin as an example
**\<Isthmus>** Chicken/egg, don't need numbers for the framework
**\<sgp\_>** I see your point Isthmus
**\<Isthmus>** Does buffering the lock time to be greater than the worst case plausible scenario make sense as a framework?
**\<sarang>** dEBRUYNE: but most clients use the 6-confirmation rule for "confirmed" transactions
**\<suraeNoether>** Isthmus: if we did this, our lock time would have to be >> 23
**\<sarang>** I was curious about that particular choice's assumptions
**\<suraeNoether>** iirc we saw a 23-block reorg recently
**\<dEBRUYNE>** It is a soft rule essentially
**\<dEBRUYNE>** You can easily overrule it
**\<sgp\_>** Let's consider a 3 standard deviation scenario
**\<sarang>** dEBRUYNE: right, but I'm simply curious to make a comparison
**\<Isthmus>** Lock\_time = Safety\*(max(len\_latency, len\_51%, len\_selfish...))
**\<Isthmus>** So if you're saying that would be 23
**\<Isthmus>** You're saying lock
**\<Isthmus>** lock\_time = 23
**\<Isthmus>** What are you using as your value for the Safety term?
**\<Isthmus>** And which term in the max are you looking at?
**\<suraeNoether>** ah, good questions
**\<Isthmus>** I never suggested any value for the safety term, so I'm trying to figure out how we got to 23 :- P
**\<suraeNoether>** no no
**\<suraeNoether>** that's not the 23
**\<suraeNoether>** i'm saying max(...) > 23, because we've seen 23 within the last year
**\<Isthmus>** Woah, I totally missed that
**\<Isthmus>** When?
**\<suraeNoether>** so whatever number we select needs to be > safety\*23
**\<Isthmus>** We can fish it out of the NRL logs
**\<sarang>** That was from a single node report, no?
**\<suraeNoether>** sarang: \*shrug\* even if it was 15, or 12, safety\*12 for any safety > 1 is going to be bigger than 20, generally
**\<sgp\_>** That's why I think looking at all reogs and using 3sd longer than normal or something like that is a more practical number
**\<suraeNoether>** my point is: if we look at how common re-orgs are, and if we want to protect against those, we need unreasonably long lock times that risk slowing down the monero economy
**\<sarang>** sgp\_: all observed reorgs, regardless of assumed origin (latency, high-hashpower entity, etc.)?
**\<sgp\_>** sarang: I would need to go deeper into the numbers, but I just want to see what the numbers are without some of the outliers
**\<Isthmus>** I've been out of the loop, so I'm not disagreeing. But wowza, I hadn't seen anything \*global\* greater than length 2 since we switched to CryptoNoteR
**\<suraeNoether>** sgp\_: \*nod\* we should look at the distribution of re-org times, though, and decide on a rigorous statistic instead of picking 3\*stdev, but your point is 100% correct
**\<sgp\_>** that's the overall point I want to convey
**\<ArticMine>** I suggest a risk based approach. Starting with who bears the risk?
**\<sgp\_>** eg: if there was 1 reog at 20 and every other one is \<3, that's important to know
**\<sarang>** I think using data and methods from the Bitcoin community for risk estimates of high-hashpower entities would be useful as one data point
**\<sgp\_>** Isthmus: in terms of the framework however, I think we need to add some privacy implications
**\<Isthmus>** True, though the Gini coefficient for BTC hashrate is probably much more lopsided that Monero's distribution
**\<sgp\_>** shrinking the lock time likely has adverse privacy implications
**\<sgp\_>** and it also have positive UX implications
**\<ArticMine>** There are some significant differences in Bitcoin: 1) Great Firewall of China 2) 10 min blocks
**\<Inge->** Better UX at the cost of privacy sounds like ... not-Monero.
**\<Isthmus>** I suspect (and I may totally backtrack this later...) that the fact we flip coins every 2 minutes rather than every 10 minutes may mean we reach stable equilibrium faster
**\<sgp\_>** Inge-: it's about the tradeoff. No one would use a coin with a lock time of 100 days
**\<Isthmus>** SLOWNERO
**\<Isthmus>** YESSSS
**\<suraeNoether>** ^ nah, it's like using a smooth/exponential curve for a mortgage versus discretized timesteps using monthly annualization formulas: one approximates the other, but you converge at the same rate
**\<suraeNoether>** wrt 2 minus vs 10
**\<suraeNoether>** okay, let's operate briefly assuming that the longest reasonable "natural" re-org is 6 blocks. it's smaller than our current lock time, longer htan isthmus' global data, and matches satoshi's arbitrary selection.
**\<suraeNoether>** if we pick safety = 2 or 3, we are still looking at 12 or 18 lock time, not shorter than 10.
**\<suraeNoether>** now, if we recall, block re-orgs don't always happen naturally and can take place due to adversarial behavior, using the longest one in history is incomplete
**\<suraeNoether>** why? the attacker may hold off, biding their time on a real attack, until their attack power is most likely to lead to success. Seeing only a few re-orgs of length 2-6 in the entire history of monero doesn't mean that an adversary can't force a 30-length re-org, as an example, so while the monero archival stuff that isthmus has been running is helpful
**\<suraeNoether>** i dunno, i feel like this is an unnecessary rabbit hole
**\<sgp\_>** "past performance does not indicate future results." But I still like seeing how the network performs under normal scenarios
**\<suraeNoether>** or at least: why try to select a number other than 10 before the next hard fork?
**\<suraeNoether>** sgp\_: well... \*historical\* scenarios anyway
**\<ArticMine>** So do we just stay with 10?
**\<sgp\_>** let's agree on the framework first :)
**\<sgp\_>** if we don't agree on anything, the status quo will remain (10)
**\<Isthmus>** Oh totally NOT trying to adjust this by the next fork
**\<Isthmus>** This is going to take us like 3 months to discuss
**\<suraeNoether>** oh, then if that's the case
**\<Isthmus>** I was just responding to the ping from last meeting
**\<Isthmus>** I think enforce at 10 for this upcoming upgrade
**\<Isthmus>** Ahhahaha
**\<Isthmus>** Re @suraeNoether "this is an unnecessary rabbit hole", As MRL, if we are going to inform lock time, we HAVE to go down three rabbit holes. 1) What's the longest plausible natural reorg, 2) What's the longest plausible attack, 3) what margin of error do we want?
**\<Isthmus>** I literally don't think there's a way to address the question if we're not willing to consider these
**\<Isthmus>** (I think... there may be some clever way to circumvent this...)
**\<suraeNoether>** i'm saying there is not a way to address this problem
**\<Isthmus>** What do you think about additive safety term versus multiplicative?
**\<sgp\_>** suraeNoether: I agree on a theory level, but not on a practical level
**\<suraeNoether>** sgp\_: yeah, i'm saying theoretically, there is no optimal solution. in practice, there will be a whole host of solutions that are "good enough" that have different tradeoffs between them depending on threat models
**\<sgp\_>** ....have you worked on Monero before? lol
**\<suraeNoether>** this is why isthmus is using the word plausible here
**\<suraeNoether>** ...
**\<sgp\_>** yeah it's a tradeoff, but we need to pick one, and there's potential reason to believe (with evidence) that a number other than 10 is best
**\<suraeNoether>** \*cough\* there is no best solution
**\<sgp\_>** I'm open to changing the number with the right evidence
**\<Isthmus>** Maybe we can circle back to this next week with more recent numbers from the archival network regarding global events
**\<ArticMine>** Is it not possible to take a risk based approach for a framework?
**\<Isthmus>** @ArticMine yes, please share ideas :- )
**\<ArticMine>** 1) % hashrate of attacker
**\<ArticMine>** 2) Who bears the impact
**\<ArticMine>** 3) Type of impact ie double spend, privacy
**\<ArticMine>** One should be able to derive risk provabilities
**\<Isthmus>** Some of #1 may be captured in Eq 3. Or at least I tried.
**\<Isthmus>** https://usercontent.irccloud-cdn.com/file/iRNSWEPW/image.png
**\<sarang>** Again, that Bitcoin-related paper does this type of hashrate-threshold analysis
**\<ArticMine>** Yes this is the type of analysis I mean
**\<suraeNoether>** 1) lock times > 50 or \< 10 are extremely bad ideas for opposing reasons.
**\<suraeNoether>** 2) This leaves a narrow band of a half of a single order of magnitude. not a lot of wiggle room.
**\<suraeNoether>** 3) going from 10 to 15 is extremely unlikely to have a dramatic or concrete impact on privacy; this is a 10 minute difference when we are speaking of distributions with medians around a day and a half
**\<suraeNoether>** 4) Going from 10 to 40 is going to have huge impacts on our economy, and would have to be justified by a veritable mountain of evidence
**\<suraeNoether>** i look at this as willfully entering into analysis paralysis just because we have the data to answer questions about some very specific hypotheses
**\<sarang>** In the interest of time, may we table this and return when folks have had a chance to review the relevant analysis?
**\<sgp\_>** yes please
**\<sarang>** Isthmus had one other item to discuss
**\<Isthmus>** So, I might not have 100% of the technical details right, so feel free to jump in with corrections:
**\<sarang>** It was the question of tx pubkey representation, since its use is different between primary and subaddresses
**\<Isthmus>** Yes, that.
**\<Isthmus>** The ability for an external observer to ascertain whether there were any subaddresses included in the construction of a transaction
**\<Isthmus>** Leaks information about the recipient
**\<moneromooo>** Or sender.
**\<sarang>** For some reason I thought that unique pubkeys were always used now, regardless of address type, to reduce distinguishability... but I need to check this
**\<Isthmus>** Yes, and/or sender
**\<dEBRUYNE>** sarang: Sure, that is fair, but in that instance I would set it to zero
**\<sgp\_>** This is the first I am hearing of this
**\<moneromooo>** Actually... I'm not sure. The logic is a bit different for change IIRC...
**\<suraeNoether>** i'm a bit confused...
**\<moneromooo>** I hit that when I tried to add custom change addresses.
**\<suraeNoether>** isthmus do you have a small toy example you could show us?
**\<Isthmus>** Nope, I have no clue how the constructions differ
**\<sarang>** suraeNoether: for subaddress destinations, you use a unique tx pubkey
**\<Isthmus>** Well wait
**\<Isthmus>** Maybe I can fish up an example
**\<Isthmus>** Does tx\_extra = (empty) imply no subaddresses were involved?
**\<Isthmus>** In that case I can just hit a block explorer
**\<sarang>** tx\_extra stores tx pubkey, which is always included
**\<suraeNoether>** sarang: do you mean the tx pubkey is encoded differently?
**\<suraeNoether>** oh oh
**\<suraeNoether>** yeah
**\<sarang>** yes
**\<suraeNoether>** aha
**\<Isthmus>** Mmmmm
**\<sarang>** It's derived differently for primary and subaddresses
**\<sarang>** It's possible to use only one pubkey for multiple non-subaddress destinations
**\<sarang>** but this implies distinguishability
**\<Isthmus>** ^^^^
**\<suraeNoether>** hmm
**\<sarang>** I thought this had been changed to be unique per destination all the time, for this reason
**\<suraeNoether>** sarang i am beginning to recall this conversation and using a unique key per destination, and we didn't like that it revaled the number of dest addresses, or something...
**\<sarang>** Unique per output, is what I should have said
**\<sgp\_>** why would the # of dest addresses be different than the number f outputs, unless someone is doing terrible churn?
**\<suraeNoether>** \*shrug\* users do dumb stuff all the time for dumb reasons
**\<sarang>** I will confer with moneromooo and examine code to see what the current default behavior is
**\<Isthmus>** +1
**\<moneromooo>** I purposefully shut up after what I said above since stoffu will know for sure, and I don't.
**\<Isthmus>** Cool, I think we can probably stick a pin in this, research over the week, and circle back with more concrete details about distinguishability under the current design.
**\<ArticMine>** +1
**\<sarang>** OK, any other action items before we adjourn?
**\<sarang>** Righto, thanks to everyone for participating

27
_posts/2019-10-10-logs-for-the-tini2p-dev-meeting-held-on-2019-10-10.md Normal file
View File

@ -0,0 +1,27 @@
---
layout: post
title: Overview and Logs for the tini2p Dev Meeting Held on 2019-10-10
summary: Current project status, Roadmap, Meta issues, and miscellaneous
tags: [dev diaries, i2p, crypto]
author: el00ruobuob / oneiric
---
# Logs
**\<tini2p\_gitlab>** greetings
**\<tini2p\_gitlab>** 1: What's been done
**\<tini2p\_gitlab>** alpha release is live!
**\<tini2p\_gitlab>** master branch is tagged for alpha release 0.0.1
**\<tini2p\_gitlab>** there are likely still bugs, and refactors that need to be done
**\<tini2p\_gitlab>** but all the pieces are in place for the core router
**\<tini2p\_gitlab>** tini2p is capable of end-to-end sessions over I2P tunnels
**\<tini2p\_gitlab>** tini2p is NOT currently capable of communication with Java I2P, i2pd, or ire routers
**\<tini2p\_gitlab>** in the coming weeks, I will be working on ElGamal tunnel building to enable communication with Java I2P, i2pd, and ire
**\<tini2p\_gitlab>** point-to-point communication over NTCP2 is likely possible with Java I2P/i2pd/ire, but I haven't tested it at this point
**\<tini2p\_gitlab>** anyone interested is welcome to pull the latest master, and test stuff out
**\<tini2p\_gitlab>** any testing is very much appreciated
**\<tini2p\_gitlab>** release is three months past the initial planned alpha, and I am grateful for the support and patience
**\<tini2p\_gitlab>** my goal is to add client functionality, a fuzzing test suite, and core refactors by December
**\<tini2p\_gitlab>** will have a longer meeting next week
**\<tini2p\_gitlab>** 2: Next meeting time
**\<tini2p\_gitlab>** 2019-10-17 18:00 UTC

192
_posts/2019-10-12-logs-for-the-Community-meeting-held-on-2019-10-12.md Normal file
View File

@ -0,0 +1,192 @@
---
layout: post
title: Logs for the Community Meeting Held on 2019-10-12
summary: Community highlights, CCS updates, Workgroup report, and miscellaneous
tags: [dev diaries, community, crypto]
author: el00ruobuob / SamsungGalaxyPlayer
---
# Logs
**\<sgp\_>** yes indeed
**\<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/400
**\<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. Fun fact: we’ve been doing these since issue #79.
**\<sgp\_>** 1. Greetings
**\<OsrsNeedsF2P>** I like fun facts
**\<el00ruobuob>** Hi!
**\<rottensox>** o/ the rottenest sox present.
**\<rehrar>** here'
**\<needmonero90>** Hey all
**\<sgp\_>** welcome everyone
**\<sgp\_>** 2. Community highlights
**\<sgp\_>** See Monero weekly highlights at https://revuo-monero.com/
**\<sgp\_>** Reminder that 0.15 is expected on October 31, with the scheduled protocol upgrade on November 30: https://web.getmonero.org/2019/10/01/announcement-release-0-15.html
**\<sgp\_>** There's a help thread in https://reddit.com/r/monero if you need assistance or have specific questions
**\<sgp\_>** Monero Talk interviewed Brad Mines, Daniel Krawisz, and spesmonerujo in the past two weeks: https://youtube.com/c/monerotalk
**\<monerobux>** [ Monero Talk - YouTube ] - youtube.com
**\<sgp\_>** Are there any outstanding questions regarding the upcoming update, or does anyone have community (non-workgroup) updates to share?
**\<OsrsNeedsF2P>** I'm planning on releasing a 1.0 version of MoneroTipsBot soon
**\<needmonero90>** I'm curious which exchanges are still in limbo wrt subaddresses
**\<OsrsNeedsF2P>** Oh u first ^
**\<needmonero90>** as usual, I would like an updated listing of who needs contacting, so we can rally people to shoot off pings
**\<needmonero90>** As the network upgrade approaches, this becomes more and more important :)
**\<sgp\_>** indeed. needmonero90, want to take the initiative? :)
**\<needmonero90>** I already am with binance actually
**\<needmonero90>** I've been keeping in contact with them regarding the deadline
**\<sgp\_>** Polo is good I know. What about Kraken? Shapeshift? MorphToken?
**\<needmonero90>** debruyne any idea who is left?
**\<rottensox>** TradeOgre. :-)
**\<mooman12>** tradeogre don't use unencrypted payment id do they?
**\<rottensox>** .shrug
**\<monerobux>** ¯\\\_(ツ)\_/¯
**\<ErCiccione[m]>** Hi
**\<needmonero90>** hi
**\<sgp\_>** not sure about Bitfinex either
**\<sgp\_>** maybe a thread on r/xmrtrader is best for this honestly
**\<needmonero90>** I heard the mods there are really strict
**\<needmonero90>** (I'll make a post)
**\<sgp\_>** like ~~we~~ others do a thread for mining pools on r/moneromining
**\<OsrsNeedsF2P>** ^\_^
**\<needmonero90>** Ok, on to osrs's question. I'll make an exchange post on xmrtrader today.
**\<sgp\_>** yeah I think that's best
**\<mooman12>** Snipa: does supportxmr still have anyone mining to an address with payment id?
**\<sgp\_>** oh that's a good question
**\<sgp\_>** could email them and tell them to stop if they are registered
**\<rottensox>** sgp\_: https://imgur.com/cLtds0r.png
**\<rottensox>** Bitfinex still does have payment ID. Took it from my account right now.
**\<sgp\_>** yuck. add one to the list to pester
**\<sgp\_>** thanks rottensox
**\<mooman12>** are they even solvent? :v
**\<rottensox>** Anytime.
**\<Snipa>** Probally, I can pull the logs and check. We need to make a deprecation message, but the mining clients don't usually allow for it.
**\<sgp\_>** Snipa: let us know if there's some way to help out there. It's a clever way to reach people in a way that we typically don't
**\<Snipa>** Traditionally, M5M and I will update the main pool page with notices/announcements of this nature.
**\<rottensox>** sgp\_: Morph has it too - https://imgur.com/HzaBl7I.png
**\<sgp\_>** anything else on this topic?
**\<el00ruobuob>** Kraken seems to use integrated addresses
**\<sgp\_>** rottensox: that's optional for refund, so I think it's not quite as important. It's more important when depositing Monero
**\<rottensox>** okie.
**\<sgp\_>** el00ruobuob: yeah, I believe they do
**\<sgp\_>** I can send a quick message to Morph to make sure they know
**\<sgp\_>** endogenic: is MyMonero pulling payment ID support in the wallet? (he can answer later if not here)
**\<sgp\_>** Anything else on this topic?
**\<sgp\_>** summary: check r/xmrtrader for a list soon^TM
**\<Snipa>** If there's anything else we can do on the pool side, let me know.
**\<sgp\_>** thanks Snipa, great to see you around here :)
**\<Snipa>** RandomX is throwing some bigger wrenches into the original pool designs, so everyone's sort of working things out still, but notifications are something we can sort-of do.
**\<sgp\_>** 3. CCS updates
**\<sgp\_>** There are no new proposals in ideas or funding required. Any CCS comments before we move on?
**\<sgp\_>** I'll take the silence as a no
**\<sgp\_>** 4. Workgroup report
**\<sgp\_>** a. Daemon/CLI workgroup
**\<sgp\_>** luigi1111w merged a considerable number of changes the past few weeks to substantially improve Monero’s stability. vtnerd submitted new mempool code that handles i2p transaction broadcasts.
**\<sgp\_>** b. Localization workgroup
**\<sgp\_>** ErCiccione[m]: you have the floor
**\<ErCiccione[m]>** yep
**\<ErCiccione[m]>** Not much to report, Weblate is finally online and translators already started to work. Everything seem to work without issues and contributors seem to appreciate the new platform.
**\<ErCiccione[m]>** see: translate.getmonero.org
**\<ErCiccione[m]>** i encourage everybody who can to help translate release 0.15 of GUI and CLI
**\<ErCiccione[m]>** Also,
**\<ErCiccione[m]>** while preparing weblate for GUI and CLI i tested it for the website. We can use it. Not for the complete website but at least for the main part (the LANG.yml files)
**\<ErCiccione[m]>** i will make some more testing on my private instance and see how it works out, but i'm optimist. It will make much more easier to maintain the existen translations, but won't have much inpact about adding a new one. Still a big improvement.
**\<ErCiccione[m]>** i think that's it
**\<el00ruobuob>** Great!
**\<sgp\_>** thanks ErCiccione[m]
**\<ErCiccione[m]>** for more info about how weblate works and the feature it has. there's the guide: https://github.com/monero-ecosystem/monero-translations/blob/master/weblate.md
**\<sgp\_>** very helpful
**\<ErCiccione[m]>** i would like to say a couple of things about the website, even if it's not technically a workgroup, if it's ok, sgp\_
**\<sgp\_>** sure
**\<sgp\_>** thanks for taking on that initiative btw, it's hugely important
**\<ErCiccione[m]>** my pleasure! :P
**\<ErCiccione[m]>** btw
**\<ErCiccione[m]>** moneromooo proposed to change the header of the website adding "A Reasonably" before "Private Digital Currency
**\<ErCiccione[m]>** "
**\<ErCiccione[m]>** see: https://repo.getmonero.org/monero-project/monero-site/merge\_requests/1136
**\<rehrar>** down
**\<ErCiccione[m]>** the thing is that that particular header was discussed quite a lot before it was chosen, so i thought was best to discuss that here
**\<sgp\_>** I'm also ok with "a reasonably private digital currency for all"
**\<ErCiccione[m]>** i like it too
**\<el00ruobuob>** i like it too
**\<rehrar>** i like it too
**\<ErCiccione[m]>** ooow \<3
**\<OsrsNeedsF2P>** In the privacy world, phrases like that are super popular, for instance I2P really drills in a similar idea
**\<OsrsNeedsF2P>** But it looks absolutely terrible to the uneducated user, and IMO, drives them to a less safe alternative
**\<sarang>** Terms like "private" and "untraceable" claim a lot
**\<rottensox>** ^
**\<needmonero90>** Private^[1] Digital Currency
**\<sarang>** and depend highly on risk and threat models
**\<sgp\_>** "xyc coin says it's more private," but they will say that anyway
**\<OsrsNeedsF2P>** But what about terms like "The most private [cryptocurrency]", @sarang
**\<rehrar>** we really need to remove untraceable
**\<rottensox>** no?
**\<rottensox>** lol.
**\<needmonero90>** thats arguable even, osrs
**\<needmonero90>** "but muh piratechain has mandatory zksnarks"
**\<sgp\_>** that's why I like the focus on "for all" for marketing's sake
**\<Mochi101>** Did you two make up and become lovers now?
**\<sgp\_>** it's the only privacy-focused option someone can reasonably use right now
**\<sgp\_>** from a UX perspective
**\<rehrar>** and even that is questionable :D
**\<sgp\_>** so overall, changing this phrasing is more accurate, and shills are going to shill other stuff regardless of what it says
**\<Mochi101>** obfuscated ?
**\<rehrar>** yeah, but how does the word "reasonably" look on the website?
**\<rehrar>** I'll give it a look
**\<rehrar>** in terms of spacing and stuff
**\<Mochi101>** private and obfuscated transactions
**\<rottensox>** https://twitter.com/xmranon/status/1179771671303065600
**\<monerobux>** [ xmranon on Twitter: ""Bitcoin is so much easier to use than #Monero" is such a bullshit argument. ios.cake android.monerujo web.mymonero" ] - twitter.com
**\<sgp\_>** imo, obfuscated means nothing to non-cryptrocurrency-focused people
**\<rehrar>** in other news, I am almost done with a Monero pumpkin picture that sarang requested
**\<sarang>** That's fantastic rehrar !
**\<el00ruobuob>** rehrar, it looks bad with the video that large.
**\<sgp\_>** what about the Monero pumpkin carving?
**\<rehrar>** it will be available for purchase for recurring payment of 0.1 XMR for monthly licensing
**\<sgp\_>** for the sake of time, we should move on from this specific topic. Thanks for mentioning it ErCiccione[m]
**\<sgp\_>** Do you have anything else to talk about related to the website?
**\<rehrar>** el00ruobuob: opinions need to be justified
**\<sgp\_>** el00ruobuob: screenshot + comment on Gitlab please :)
**\<rehrar>** oh wait
**\<rehrar>** you mean the changed version, not the version as is
**\<rehrar>** got it, I'll check
**\<ErCiccione[m]>** sgp\_: yes, user guides and dev guides need to be updated. I would totally support a CCS with that goal
**\<sgp\_>** oh for sure
**\<ErCiccione[m]>** or anybody who wish to pick up some of the issues labelled help needed: https://repo.getmonero.org/monero-project/monero-site/issues?label\_name%5B%5D=%E2%9B%91%EF%B8%8F++help+needed
**\<el00ruobuob>** done sgp\_
**\<ErCiccione[m]>** that's basically it. Please comment on mooo's issue about that header, because if we want to change it completely, that should be an entire different discussion
**\<sgp\_>** Thanks ErCiccione[m]
**\<sgp\_>** I'll pay more attention to GitLab
**\<sgp\_>** c. GUI workgroup
**\<sgp\_>** xiphon made improvements to remove long payment IDs and to better handle nodes in simple mode.
**\<sgp\_>** d. Monero Research Lab
**\<sarang>** Hi
**\<sgp\_>** hello sarang, take it away!
**\<sarang>** There's been a lot of work on transaction protocols from me, and on graph analysis frameworks from suraeNoether
**\<sarang>** I'll be joining rehrar and Daniel Kim at a developer conference later this month, where I'll talk about transaction protocols and how fungibility and privacy come into play
**\<rottensox>** :-D
**\<sarang>** I'm happy to answer particular questions, but don't want to bore with details on protocol design here
**\<rehrar>** oof. More Vegas.
**\<sarang>** Looking forward to speaking to a develop audience
**\<sarang>** \*developer
**\<sarang>** Of note is that RCT3 was updated fairly recently, as was Lelantus
**\<sarang>** and rockstart contributor RandomRun had an idea on extending a particular Groth proof that I've been working on
**\<sarang>** we're calling that protocol-in-progress Triptych
**\<sarang>** (no security model for it yet, though)
**\<sgp\_>** thanks sarang, anything else?
**\<sarang>** Those are the broad topics of research interest lately
**\<nioc>** catching up, I thought bittex was also using unencrypted PIDs
**\<nioc>** bittrex
**\<sarang>** shapeshift still uses them too, afaik
**\<rottensox>** We moved on, but I can quickly log in and check.
**\<sgp\_>** any final updates? we will skip over open ideas for time
**\<sgp\_>** last comments
**\<rehrar>** ne
**\<sgp\_>** was a good meeting everyone :)
**\<sgp\_>** 6. Confirm next meeting date/time
**\<sgp\_>** The next community meeting will be in 2 weeks on 26 October at 17:00 UTC. The next Coffee Chat will be on 19 October at 16:00 UTC.
**\<sgp\_>** Stick around after the meeting for a new initiative! We’re playing 0 A.D., an open-source, real-time strategy game. This event helps promote the community by focusing on something other than Monero. We hope you join us and have fun watching us mess around! https://www.youtube.com/watch?v=DqIJmY3cOO4
**\<monerobux>** [ 0 A.D. Territory Rush with the Monero Community - YouTube ] - www.youtube.com
**\<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.

106
_posts/2019-10-14-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-10-14.md Normal file
View File

@ -0,0 +1,106 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-10-14
summary: Sarang work, Surae work, and miscellaneous
tags: [dev diaries, community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** GREETINGS
**\<suraeNoether>** howdy!
**\<sgp\_>** Hello
**\<sarang>** Small crowd today, apparently
**\<sarang>** Even so, we carry on
**\<sarang>** Let's move to ROUNDTABLE
**\<sarang>** I've been working on a few things this past week
**\<sarang>** First is getting caught up with the usual literature review
**\<sarang>** Second was finalizing things for World Crypto Conference and some background research associated to that
**\<sarang>** Third was getting balance proofs working in Triptych, which is now successful
**\<xmrmatterbridge> \<serhack>** hello
**\<sarang>** This means that Triptych now supports a single proof showing all spends, correct key image construction, and balance
**\<suraeNoether>** nice!
**\<sarang>** How about you, suraeNoether?
**\<suraeNoether>** i've been furiously debugging my matching code as my primary task. there are some persistent problems. i wanted to finish this weekend but it didn't happen
**\<sarang>** Earlier you had indicated some known bugs... are these the same?
**\<suraeNoether>** no... every problem i solve reveals like... a small handful of new bugs, but the newer and newer bugs are becoming less frequent and less severe
**\<suraeNoether>** it \*feels\* like there's a single problem lurking that will cause the house of cards to stop falling down
**\<suraeNoether>** i'm very close.
**\<suraeNoether>** i really wanted it to be today
**\<suraeNoether>** i'm taking a break later today to read sarang's WCC talk (sorry for the delay on that) and I am taking a break later today to work on \*literally anything else\*
**\<suraeNoether>** i'm very frustrated with this project
**\<sarang>** Are the known bugs documented anywhere, so others might assist you?
**\<suraeNoether>** i'm sure a lot of community members are also frustrated, but i this is nearing completion
**\<suraeNoether>** no
**\<suraeNoether>** "test X not working for unknown reason" is not a helpful document to write
**\<sarang>** Hmm ok
**\<sarang>** Well, I selfishly hope you will take time off that project today and review my talk :D
**\<sarang>** Perhaps it will also help you clear your head
**\<sarang>** Does anyone else have interesting research to share as well?
**\<sarang>** In that case, let's go ahead and discuss ACTION ITEMS first, and then any lingering questions
**\<sarang>** First, I have an efficient verifier for the inner-product argument in IACR/944 that I've been meaning to implement in kenshamir[m]'s Rust code, which will be useful for benchmarking... that's in progress but with some algebra problems that I'm working out
**\<sarang>** Second, Triptych needs plenty more work: key aggregation, better Fiat-Shamir challenges, and some questions on proof elements and efficiency
**\<sarang>** Third, I want to see if it's possible to backport some of the new RCT3 changes to the older version without using spend aggregation, to check the resulting efficiency
**\<sarang>** and that's about it for now
**\<sarang>** suraeNoether: ?
**\<suraeNoether>** pushing this commit once my code is flowing. reading your WCC talk. catching up on tryptychychch
**\<sarang>** It definitely remains to be seen how efficient we can make Triptych... but as I mentioned last week, the underlying changes to the Groth proving system are very interesting regardless
**\<sarang>** and, as before, there is no security model for it yet
**\<sarang>** All righty, are there other questions on research?
**\<sarang>** This meeting has gone quite quickly
**\<sarang>** Oh, one note about what Isthmus brought up last week regarding transaction keys and subaddresses
**\<sarang>** It is apparently still the case that transactions to only standard addresses retain a single transaction key
**\<sarang>** Mandating separate transaction keys for all outputs would add 32 bytes to each additional output
**\<sgp\_>** Standard = 4?
**\<sarang>** but we're already saving > 32 bytes per output after the last change to the Pedersen mask format anyway
**\<moneromooo>** Could there be a way to deterministically generate keypairs in such a way that the sender generates the secret keys from a seed, the recipients generate the pubkeys ? I think Bitcoin has such a scheme for generating addresses.
**\<moneromooo>** And hopefully the seed is \<= 32 bytes :)
**\<sarang>** Well, a big selling point of subaddresses is the efficient scanning across all addresses at once
**\<sarang>** Isthmus: only need to read up a few lines
**\<moneromooo>** Would such a scheme invalidate the efficient scanning ? It seems doubtful since the tx keys are currently arbitrary.
**\<sgp\_>** How much effort is it to scan and see what proportion of transactions are only to standard addresses?
**\<sarang>** sgp\_: to get a distribution of how common subaddresses are?
**\<Isthmus>** @sgp\_ I think that @n3ptune accidentally did that recently
**\<Isthmus>** Lemme see if the plots are on GitHub anywhere
**\<sgp\_>** sarang: essentially yes
**\<sarang>** Presumably this would be affected by which large players (like exchanges) support them
**\<sgp\_>** Thanks Isthmus
**\<Isthmus>** https://github.com/noncesense-research-lab/tx\_extra\_analysis/blob/master/tx\_extra\_viz.ipynb
**\<sarang>** 404
**\<Isthmus>** Oh, private repo. Lemme grab the juicy parts
**\<Isthmus>** This might be the relevant one
**\<Isthmus>** https://usercontent.irccloud-cdn.com/file/LgrrzOIS/image.png
**\<Isthmus>** I suspect the diagonal is transactions that include a subaddress, while the horizontal bands are primary-only
**\<Isthmus>** Though I'm open to alternate interpretations
**\<moneromooo>** Oh I get it. The fast lookup would still exist, but verifiers would have to generate pubkeys, and \*that\* might be slow.
**\<sgp\_>** Thanks
**\<Isthmus>** If that is the case, then I can slide a window over time and calculate fraction of transactions that appear to include no subaddresses
**\<sgp\_>** I'm not the one who can say yes or no to that :/
**\<sarang>** Probably worth bringing up at the next dev meeting to see what others think of it
**\<moneromooo>** It is trivial to know whether >= 1 subaddress was used as an output in a tx.
**\<moneromooo>** If that was the question...
**\<moneromooo>** Oh wait. Maybe not, there's some funky going on with change being treated differently...
**\<sgp\_>** A more meta question: how did this happen? What could have been done differently to help prevent this from happening?
**\<sarang>** That's probably a question for someone like stoffu who was more directly involved in the code
**\<sarang>** I suspect space saving was one consideration
**\<sgp\_>** knaccc too?
**\<sarang>** but it's quite minor for the most part
**\<Isthmus>** @sgp\_ meta answer: we rolled out a new feature that:
**\<Isthmus>** 1) you could tell use from blockchain as external observer
**\<Isthmus>** 2) was optional
**\<Isthmus>** Either one of those alone is ok, but together we end up in this situation.
**\<sgp\_>** I always assumed 1 wasnt the case. I was very misinformed and thus misinformed others
**\<Isthmus>** Yeah, I think we're all just putting 2+2 together on that now
**\<sarang>** OK, something to discuss at next dev meeting, then
**\<sarang>** Are there any other topics to discuss for this meeting?
**\<Isthmus>** Oh yea, lemme grab a link
**\<Isthmus>** The CryptoEconSec paper by hasu and all is very interesting, and parts are relevant to both Monero and our lock time conversation
**\<Isthmus>** \*et al
**\<Isthmus>** I definitely recommend reading it. Very approachable.
**\<Isthmus>** Here's the writeup: https://uncommoncore.co/research-paper-a-model-for-bitcoins-security-and-the-declining-block-subsidy/
**\<Isthmus>** And here is my analysis: https://twitter.com/Mitchellpkt0/status/1183581226357014528
**\<Isthmus>** I won't rehash it all here. Just take a pass through on your next commute. :- )
**\<sarang>** Thanks Isthmus
**\<sarang>** Any last questions before we adjourn and continue discussions?
**\<sarang>** Righto, thanks to everyone for attending!

46
_posts/2019-10-17-logs-for-the-tini2p-dev-meeting-held-on-2019-10-17.md Normal file
View File

@ -0,0 +1,46 @@
---
layout: post
title: Overview and Logs for the tini2p Dev Meeting Held on 2019-10-17
summary: Current project status, Roadmap, Meta issues, and miscellaneous
tags: [dev diaries, i2p, crypto]
author: el00ruobuob / oneiric
---
# Logs
**\<tini2p\_gitlab>** 0: Greetings
**\<tini2p\_gitlab>** h
**\<tini2p\_gitlab>** 1: What's been done
**\<tini2p\_gitlab>** last week was the alpha release of tini2p
**\<tini2p\_gitlab>** the router is still in its earliest stages, and things will still be changing fairly drastically as refactors and bug fixes are made
**\<tini2p\_gitlab>** tini2p routers are capable of building ECIES tunnels, and communicating end-to-end via ECIES-X25519
**\<tini2p\_gitlab>** NTCP2 (a tcp-like transport) is fully implemented
**\<tini2p\_gitlab>** cross-implementation testing is still needed to discover and remedy any bugs (if they exist)
**\<tini2p\_gitlab>** the router is also currently compiled with a testnet netID to mitigate any communication with mainnet routers
**\<tini2p\_gitlab>** using a testnet netID means custom compilation is required to communicate with mainnet I2P routers over NTCP2
**\<tini2p\_gitlab>** I haven't added the necessary build for mainnet because tini2p isn't ready yet, and I don't want to encourage usage which may be disruptive/harmful to the network
**\<tini2p\_gitlab>** I also began work on [ElGamal tunnel building](https://gitlab.com/tini2p/tini2p/commits/elg-tunnel) (basic encryption/decryption of BuildRequestRecords is more-or-less done)
**\<tini2p\_gitlab>** 2: What's next
**\<tini2p\_gitlab>** will continue work on ElGamal tunnel building
**\<tini2p\_gitlab>** the next steps are:
**\<tini2p\_gitlab>** - serializing/deserializing ElGamal BuildRequestRecords (slightly different from ECIES records)
**\<tini2p\_gitlab>** - deriving keys for ChaCha tunnels using the ElGamal shared secret
**\<tini2p\_gitlab>** - refactoring the router context to handle ElGamal tunnel building
**\<tini2p\_gitlab>** maybe it will go quickly, but it could take a couple weeks
**\<tini2p\_gitlab>** will also work on creating test vectors for i2pd and Java I2P for cross-impl ElGamal testing
**\<tini2p\_gitlab>** will bring up KDF discussion about deriving record keys using the ElGamal shared secret
**\<tini2p\_gitlab>** for AES tunnels, deriving record keys is likely unnecessary, since any saved space would be consumed with random padding
**\<tini2p\_gitlab>** for ChaCha tunnels, the saved space is necessary for transmitting the AEAD `receive` key to each hop
**\<tini2p\_gitlab>** the additional 32 bytes for the AEAD key will not fit in the current space allocated for "options/random padding"
**\<tini2p\_gitlab>** + the bytes for the options header + flags
**\<tini2p\_gitlab>** will also be adding fuzz test drivers for data structures with `deserialize` methods as I work on other features
**\<tini2p\_gitlab>** if the KDF changes for ElGamal records are unwanted/unworkable, ElGamal tunnels will only be able to use AES for layer encryption
**\<tini2p\_gitlab>** which would effectively mean any tunnel with one ElGamal hop must use AES layer encryption for the entire tunnel
**\<tini2p\_gitlab>** if the KDF changes are accepted, ElGamal tunnels will be able to use AES and/or ChaCha layer encryption
**\<tini2p\_gitlab>** for a review of AES layer encryption: https://geti2p.net/en/docs/tunnels/implementation
**\<tini2p\_gitlab>** and ChaCha layer encryption proposal: https://geti2p.net/spec/proposals/153-chacha20-layer-encryption
**\<tini2p\_gitlab>** 3: Questions / comments
**\<tini2p\_gitlab>** much love for the lurkers
**\<tini2p\_gitlab>** 4: Next meeting time
**\<tini2p\_gitlab>** 2019-10-31 18:00 UTC
**\<tini2p\_gitlab>** @tini2p\_gitlab gavels the gavels like it's never been gavelled before

113
_posts/2019-10-20-logs-for-the-dev-meeting-held-on-2019-10-20.md Normal file
View File

@ -0,0 +1,113 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2019-10-20
summary: Development status, 0.15 release discussion, Network upgrade naming, and miscellaneous
tags: [dev diaries, core, crypto]
author: el00ruobuob / rehrar
---
# Logs
**\<rehrar>** Alright everyone. 17 UTC.
**\<rehrar>** Meeting time.
**\<rehrar>** 1. Greetings
**\<hyc>** hey
**\<rbrunner>** Hi
**\<kinghat>** \\o/
**\<rehrar>** small crowd today?
**\<sech1>** hi
**\<rehrar>** well, perhaps people will trickle in.
**\<rehrar>** Two weeks ago I was at HCPP, so I wasn't able to be here for a meeting. Was there one?
**\<dEBRUYNE>** I am here
**\<rbrunner>** No, neither 1 week ago
**\<dEBRUYNE>** I think we decided to postpone it
**\<rehrar>** ok, so
**\<rehrar>** 2. What's been completed since the previous meeting (a month ago)
**\<hyc>** a lot of PRs got merged
**\<hyc>** has the v12 forkheight been merged?
**\<moneromooo>** You can now sync off pruned nodes.
**\<moneromooo>** Not yet.
**\<dEBRUYNE>** I think that will probably be on the last merge list before we branch
**\<dEBRUYNE>** ^ rehrar
**\<moneromooo>** vtnerd\_\_: do you intend your latest network changes to go in for the fork ?
**\<vtnerd\_\_>** the one that is up for review, yes that would be the hope (provided its determined to be ready)
**\<vtnerd\_\_>** its not needed for the hardfork, so if you feel it should wait, then my recommendation would be to wait for a point release
**\<vtnerd\_\_>** the problem is that re-testing some of your recommendations are likely to take up time before the upcoming branch, but I will try
**\<moneromooo>** I think that and pay-for-service are the only large ones left.
**\<moneromooo>** Oh, and the defer tx verification one. Not huge either but a bit substantial.
**\<rehrar>** are either of those expected to be in?
**\<moneromooo>** Hopefully all of them.
**\<moneromooo>** pay-for-service goes next, I've kept it waiting for long enough.
**\<hyc>** sounds good
**\<rbrunner>** Did I get that right that a PR is waiting in that batch that will cause testnet to reorg back to some much earlier blockheight?
**\<hyc>** not that I've seen
**\<hyc>** ?
**\<rbrunner>** Maybe I misunderstood then, while reading something up here
**\<moneromooo>** I said so, but I was wrong. The rules are different, but actually coincide in practice.
**\<rbrunner>** Surprising
**\<rbrunner>** All the better
**\<moneromooo>** They'll stop conciding whe nthe block size shoots up.
**\<rbrunner>** So we only need some seed nodes working for testnet ... caugh ... caugh
**\<moneromooo>** gingeropolous added one, that'll be merged soon.
**\<rbrunner>** Nice
**\<hyc>** dEBRUYNE: didn't you get hold of fluffypony regarding seed nodes?
**\<dEBRUYNE>** He posted an update here 1-2 days ago
**\<dEBRUYNE> \<fluffypony>** re: testnet nodes, I've been having some issues with the boxes I run, but there are other people running testnet nodes besides me
**\<hyc>** ah, I missed that. ok
**\<rbrunner>** Especially nice that stagenet gets a third seed node, with the only two so far probably just sitting side-by-side and offering zero redundancy
**\<rbrunner>** well, not zero, but you get what I mean ...
**\<rehrar>** Anything else of note to discuss on what's been done this past month?
**\<hyc>** sounds like not
**\<rehrar>** Alrighty.
**\<rehrar>** 3. Fork related things
**\<rehrar>** is there anything that is needed, desired, wanted, or otherwise needs to be discussed regarding the upcoming fork.
**\<tevador>** FYI, there will be probably RandomX 1.1.5 with some OpenBSD-related fixes
**\<tevador>** but best if 1.1.4 is merged first (1.1.5 doesn't need any changes in monero code)
**\<hyc>** that's PR#5980 for v1.1.4
**\<tevador>** yes
**\<rehrar>** ok, no other fork related topics? If not we can move on.
**\<rehrar>** Zipping through this meeting.
**\<rehrar>** is anyone from GUI here? dsc\_ selsta
**\<selsta>** yes we only had bug fixes recently
**\<selsta>** GUI is ready for v0.15
**\<rehrar>** ok
**\<rehrar>** 4. Any Ticket/PR related questions?
**\<rbrunner>** By the way, is there already a final name for the release? I could use it for adjusting the Windows installer. Is it now crab something?
**\<hyc>** carbon crab?
**\<hyc>** I don't recall a final name decision
**\<rbrunner>** Yeah, that one
**\<rehrar>** Where was the discussion?
**\<rbrunner>** Me neither, that's why I ask for sure
**\<rehrar>** We can make a decision here.
**\<rbrunner>** I think there was some chatter in a Reddit thread once
**\<hyc>** I think some names got tossed around in this channel a few weeks ago. but nothing decided.
**\<moneromooo>** camelopardalis is satifyingly complicated.
**\<rehrar>** you guys want to decide now? Or not urgent?
**\<hyc>** oh yeah, that was my suggestion
**\<moneromooo>** I think pony likes to leave it for a reddit vote where people can't break things
**\<hyc>** we can do it now, there seems to be enough people present
**\<hyc>** ah
**\<dEBRUYNE>** Pony usually makes a Github thread and links that to reddit iirc
**\<rbrunner>** I would also prefer a Reddit thread, more fun for the fans, so to say
**\<dEBRUYNE>** (re: name)
**\<rbrunner>** But why not soon, e.g. tomorrow
**\<tevador>** does the 24th Oct code freeze still apply?
**\<tevador>** (it should)
**\<hyc>** there was a mention of name on reddit https://www.reddit.com/r/Monero/comments/d884zt/preliminary\_information\_thread\_regarding\_the/f2zfmr1/
**\<hyc>** but pretty sure that was just relaying a suggestion from here on IRC
**\<rehrar>** I can make a meta issue and link to it on the Reddit
**\<hyc>** cool
**\<rbrunner>** Yeah that was me, but I forgot where I got that Carbon Crab
**\<rbrunner>** Yes, do go ahead
**\<dEBRUYNE>** rehrar: should I ask pony first if he wants to uphold the tradition?
**\<hyc>** (I have the previous discussion in chat logs, was in this channel a couple weeks ago)
**\<moneromooo>** Callisto alliterates nicely too fwiw.
**\<rehrar>** sure
**\<rbrunner>** Hmm, yes indeed
**\<rbrunner>** "Crab" is very short
**\<rehrar>** Is there anything else to discuss besides the naming?
**\<rehrar>** Kind of a free for all time.
**\<hyc>** that's always the hardest problem in computing...
**\<rbrunner>** So it looks surprisingly good for this code-freeze
**\<rehrar>** it's because we extended it out an extra month?
**\<rehrar>** Alright, well if there's nothing else to discuss, then we can go ahead and break. Doughnuts are on the table on your way out.

74
_posts/2019-10-21-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-10-21.md Normal file
View File

@ -0,0 +1,74 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-10-21
summary: Surae work, Sarang work, and miscellaneous
tags: [dev diaries, community, crypto, research]
author: el00ruobuob / Sarang
---
# Logs
**\<suraeNoether>** Greetings everyone!
**\<suraeNoether>** My work this past week has been fruitful. Right now I'm running simulations. These are not data collection simulations yet, but if they pass testing, then I'm making a final push my repo and then data collection will begin and I'll be getting \*literal answers\* later this afternoon.
**\<suraeNoether>** this is the matching/churn project
**\<sarang>** Nice
**\<suraeNoether>** in addition to that, sarang asked yesterday: do we care more about space or time when it comes to replacing signature schemes. luckily, we can literally quantify when it is worth switching to a new scheme
**\<suraeNoether>** Just to remind the audience, here is how that derivation goes
**\<suraeNoether>** Let's say we have two possible ways of encoding a database and verifying its contents.. Case I: Size of file is O(n) and time to verify file is O(n). Case II: Size of file is O(log(n)) and time to verify file is O(n).
**\<suraeNoether>** When is it worth it to switch from Case I to Case II? In Case I, total download and verification time is a\*n/c + b\*n/v where a and b are constants, c is average download speed, and v is average verification speed (per bit)
**\<suraeNoether>** In Case II, total download and verification time is A\*log(n)/C + B\*n/V where A, B, C, and V are other constants, usually different than in Case I (although we can assume c = C for simplicity although often V != v)
**\<suraeNoether>** The total cost in time to download and verify implies that Case II is better than Case I if and only if (a/c) + (b/v) > B/V + (A/c)\*(log(n)/n). To give you guys a rough idea, when n > 10^2, log(n)/n is smaller than 0.025, so this term drops pretty quickly
**\<suraeNoether>** Since log(n)/n tends toward zero, if n is remotely large (for a blockchain we are talking about large powers of 10... and n increases as time goes on), we require a/c + b/v > B/V for this ever to be at least asymptotically a good idea to switch, and we realize that asymptotic bound pretty quickly
**\<suraeNoether>** we can run timing tests on some schemes for to estimate ballpark values of a, b, c, v, B, and V (I suspect b = B but a != A...)
**\<suraeNoether>** (these derivations are why we haven't \*yet\* switched to a sublinear scheme, by the way!)
**\<sarang>** Well, that and not having a clear winner in terms of overall efficiency+soundness
**\<sarang>** Different constructions don't necessarily scale the same way with transaction input/output structure
**\<sarang>** The logarithmic size scaling is for the size of the specified anonymity set, overall
**\<sarang>** How they handle multiple inputs/outputs makes a difference
**\<suraeNoether>** indeed, all the above is very generalized and specific formulations for specific schemes are required... besides, \*none\* of the above assumes batching
**\<suraeNoether>** although batching can be approximated by tweaking the parameters b, v, B, and V, it's still just a ballpark back of napkin thing
**\<sarang>** This past week I've worked on a few things
**\<sarang>** First, the IACR/2019/944 optimized IPA verifier was added to kenshamir[m]'s Rust implementation and benchmarked, showing no improvement over the Bulletproofs IPA
**\<sarang>** We sent a note to the authors to share our results and get some clarification on the results from their paper
**\<sarang>** But it definitively answers the question of how useful it would be in practice to use the updated verifier (answer: it wouldn't be)
**\<mikerah>** Do you have a link to @kenshamir's rust crate?
**\<sarang>** https://github.com/kenshamir/qesa
**\<sarang>** I also have Triptych balance proving working
**\<sarang>** and have completed a writeup of the algorithms
**\<sarang>** Now I'm putting correctness proofs in, which is tedious due to the algebra
**\<sarang>** There were some other modifications for efficiency too, which will need to be examined for soundness
**\<sarang>** Also of note is that last week, a side-channel issue with subaddresses was reported and examined
**\<sarang>** We discussed a fix that would essentially add a Schnorr representation proof to outputs
**\<sarang>** I'm told there is a blog post and corresponding Breaking Monero episode ready to go that describe this
**\<sarang>** This week, I plan to continue work on Triptych proofs: correctness, soundness, zero knowledge
**\<sarang>** Back to you suraeNoether
**\<suraeNoether>** This week, my action items include posting my funding request for the next quarter, assisting sarang with the soundness proof of triptych, and to actually answer some questions about churn with some rigor
**\<sarang>** Anyone have questions, or other interesting research to share?
**\<suraeNoether>** the work i've put into the infrastructure of this project has paid off, because the actual script running the tests is around 30 lines. the rest of the code is writing output to file etc
**\<suraeNoether>** (the library i wrote is 700 lines with 1200 lines of tests iirc but who counts lines anyway)
**\<sarang>** I'll be interested to see what level of support there is (or is not) for the Schnorr proof modification to avoid the subaddress side-channel attack
**\<mikerah>** I want to pass some ideas by you all around minimal smart contracts on monero.
**\<sarang>** ok
**\<mikerah>** The idea is to use FHE with a DSL to then store in the extra tx\_data field of monero transactions
**\<sarang>** DSL?
**\<mikerah>** The main problem with this is that there isn't any actual enforcement of the smart contract logic
**\<mikerah>** DSL = Domain Specific Language
**\<sarang>** It's tricky because ring signatures are, by definition, signer-ambiguous
**\<sarang>** Meaning more complex spend conditions typically don't play nicely with that
**\<mikerah>** yeah, agreed. Has anyone looked into bringing the DLSAG construct into production?
**\<suraeNoether>** DLSAG currently has some key image formatting problems :\\
**\<sarang>** Not that I know of... its scaling is still linear with the ring size, and it has a tracing problem that hasn't been solved
**\<suraeNoether>** also ^
**\<sarang>** Right, any other questions or comments before we adjourn?
**\<mikerah>** https://eprint.iacr.org/2019/1229.pdf
**\<mikerah>** Has anyone had time to skim that?
**\<mikerah>** It's the new supersonic scheme by BBS
**\<sarang>** Ah yes, I gave it the most cursory of glances
**\<suraeNoether>** it uses groups of unknown order, which is a fun but weird concept that is also used in VDFs
**\<sarang>** Even so, with certain instantiations, they estimated 7 kB or so for a 1 million-gate circuit (of some structure that I don't recall)
**\<mikerah>** My issue with constructs using groups of unknown order is what happens if a smart kid finds the order of the group?
**\<sarang>** The hardness assumption has to do with element order IIRC
**\<sarang>** among other hardness assumptions they require
**\<sarang>** Anyway, it's interesting and applicable to different proving systems
**\<sarang>** OK, I'm gonna get back to work typesetting some correctness proofs
**\<sarang>** Thanks to everyone for attending

308
_posts/2019-10-26-logs-for-the-Community-meeting-held-on-2019-10-26.md Normal file
View File

@ -0,0 +1,308 @@
---
layout: post
title: Logs for the Community Meeting Held on 2019-10-26
summary: Community highlights, CCS updates, Workgroup report, 0.15 naming discussion, and miscellaneous
tags: [dev diaries, community, crypto]
author: el00ruobuob / SamsungGalaxyPlayer
---
# Logs
**\<sgp\_>** Meeting time
**\<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/405
**\<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. Fun fact: you are awesome :)
**\<sgp\_>** 1. Greetings
**\<el00ruobuob\_[m]>** Hello!
**\<sgp\_>** ping dEBRUYNE rehrar ErCiccione[m] xmrscott[m]
**\<ErCiccione[m]>** Hi all. Thanks for the ping sgp\_
**\<sgp\_>** needmonero90 dsc\_ gingeropolous sarang
**\<gingeropolous>** yo
**\<sgp\_>** hopefully more people pour in later
**\<sgp\_>** 2. Community highlights
**\<sgp\_>** See Monero weekly highlights at https://revuo-monero.com
**\<sgp\_>** Reminder that 0.15 is expected on October 31, with the scheduled protocol upgrade on November 30: https://getmonero.org/2019/10/01/announcement-release-0-15.html
**\<needmonero90>** Oh, right, meetings are a thing on Saturdays
**\<sgp\_>** The code is frozen! Get testing!
**\<sgp\_>** We tried out a gaming session two weeks ago, and we had our coffee chat last week which was excellent despite technical challenges.
**\<sgp\_>** Are there any outstanding questions regarding the upcoming update, or does anyone have community (non-workgroup) updates to share?
**\<needmonero90>** Last coffee chat was packed
**\<needmonero90>** We need that more
**\<sgp\_>** super stacked lineup indeed :)
**\<msvb-mob>** Hello.
**\<needmonero90>** I expect you're going to link your poll soon enough, so I'll hold off
**\<sgp\_>** yup :)
**\<sgp\_>** needmonero90: can you create that update thread for exchanges in r/xmrtrader?
**\<needmonero90>** Will do during this meeting.
**\<sgp\_>** excellent
**\<thunderosa>** I guess it's a community update. The new Monero Pool UI is coming out in the next few days. Half the size, twice the speed, new features etc.
**\<sgp\_>** did someone else volunteer for the mining pool list for r/moneromining? I don't recall if I signed up for that
**\<xmrmatterbridge> \<rehrar>** Hey. I'm in Mexico right now.
**\<xmrmatterbridge> \<rehrar>** Won't be back home for a few hours.
**\<needmonero90>** Okay amigo
**\<sgp\_>** thunderosa: very cool
**\<rottensox>** what i miss.
**\<xmrmatterbridge> \<rehrar>** Left a comment on the meta issue of the meeting.
**\<sgp\_>** rehrar: yes, I added a section to discuss :)
**\<sgp\_>** let's proceed
**\<sgp\_>** 3. CCS updates
**\<sgp\_>** Funding required:'
**\<sgp\_>** Rehrar to 36C3 (4.42 / 58.65) https://ccs.getmonero.org/proposals/rehrar-36c3-expenses.html
**\<sgp\_>** Multiple features and fixes for getmonero.org: https://ccs.getmonero.org/proposals/ErCiccione-website.html
**\<sgp\_>** Ziphon’s request was overfunded! https://ccs.getmonero.org/proposals/xiphon-part-time-2.html
**\<sgp\_>** \*xiphon
**\<sgp\_>** Ideas (to be discussed):
**\<sgp\_>** WIP: Norwegian translation (3 XMR): https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/102, and
**\<sgp\_>** moneromooo, from November 2019 (395 XMR): https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/103
**\<needmonero90>** Xiphon\*
**\<needmonero90>** Oh you corrected my nad
**\<needmonero90>** Bad
**\<sgp\_>** any comments? or shall I take the silence as approval?
**\<needmonero90>** My silence is approval on everything other than the rehrar funding proposal, which has its own issues that have been discussed
**\<needmonero90>** Not sure if it's resolved, but I'll take it to back channels first
**\<needmonero90>** (issues meaning the speed at which it was merged, potential for alternatives with lower travel fees, etc)
**\<sgp\_>** sure, it's already been moved, so that complicates things a bit
**\<el00ruobuob\_[m]>** i silently approve moneromooo, looking into the Norwegian.
**\<sgp\_>** did you hope that it would be discussed during a meeting first needmonero90?
**\<needmonero90>** I can't recall where the conversation is at, so I don't want to cover old ground
**\<ErCiccione>** I suggested the guy for Norwegian to open the CCS and make the post on reddit, but i also asked to write references for his work. So, i'm waiting for those before i express my vote on that
**\<needmonero90>** Just wanted to express in meeting that that particular proposal is a thorny issue
**\<sgp\_>** all right. it was officially open for 4 days
**\<needmonero90>** Not long enough or with enough discussion imo
**\<sgp\_>** thanks ErCiccione. fwiw I find the asking amount for that proposal pretty reasonable
**\<ErCiccione>** sgp\_: I agree on that.
**\<sgp\_>** Any other CCS comments before we move on?
**\<needmonero90>** none here
**\<sgp\_>** 4. Workgroup report
**\<sgp\_>** a. Daemon/CLI workgroup
**\<sgp\_>** Code freeze. All the things happened.
**\<needmonero90>** I was confused when I saw a reddit thread about getting translations done \*before\* the freeze (maybe I misread)
**\<sgp\_>** most notably the pay-by-hash for remote node use PR
**\<needmonero90>** which didnt make sense, I thought translations and stuff were ideal after the freeze
**\<sgp\_>** needmonero90: my understanding is that there are essentially two freezes, so it depends on which one you call the "freeze." ErCiccione would be able to explain more though
**\<needmonero90>** https://www.reddit.com/r/Monero/comments/dlxyiu/monero\_translators\_we\_need\_you\_to\_make\_one\_final/
**\<monerobux>** [REDDIT] Monero translators, we need you to make one final sprint! The code freeze is imminent. (self.Monero) | 112 points (99.0%) | 15 comments | Posted by ErCiccione | Created at 2019-10-23 - 11:33:44
**\<needmonero90>** ah, okay
**\<ErCiccione>** needmonero90: translations and stuff were ideal after the freeze \<- They are, but for this release the GUI has been ready for some time, with no strings added
**\<needmonero90>** I thought code freeze meant the codebase was in a state where bugfixes and text data would be updated
**\<needmonero90>** or, thats the ideal place
**\<ErCiccione>** if there are no new strings we can start a bit earlier
**\<needmonero90>** im curious when the deadlines are for translation work
**\<ErCiccione>** the deadline was yesterday for CLI and today for GUI
**\<xmrscott[m]>** They've both come to pass
**\<needmonero90>** ah, so no translations in this release
**\<needmonero90>** no more\*
**\<sgp\_>** there were two weblate PRs I think
**\<sgp\_>** This brings up to b. Localization workgroup anyway
**\<sgp\_>** \*us
**\<ErCiccione>** needmonero90: weblate is open, if people keep translating (and approving strings), we can open another PR. But that never happens
**\<ErCiccione>** well, it's open for the CLI. GUI is locked because i pushed the translations today and they have to be merged before i unlock it
**\<sgp\_>** code freeze\* \*except for optimistic translations
**\<ErCiccione>** yeah
**\<hyc>** code freeze: no more code changes besides bugfixes
**\<hyc>** text changes, doc changes - probably still fair game
**\<needmonero90>** thats what I thought from past projects I've interacted with
**\<sgp\_>** Can we take a step back and let us know how how the localization process happened this time ErCiccione? Or any other contributor
**\<ErCiccione>** the thing is.We never had a proper code freeze, so i was usually waiting until all the features were in and then ask translators to translate,
**\<ErCiccione>** now with an actual code freeze and release week after, we had to do things a bit earlier
**\<ErCiccione>** sgp\_: sure
**\<ErCiccione>** Weblate was open since i announced it. There was few activity until my last calls for translators on reddit and twitter. I gave as a deadline the day of the beginning of the code freeze. merged those, translators can keep translate,
**\<ErCiccione>** and if there are enough strings translated i PR them to the repo (GUI or CLI) when it's possible to do so
**\<sgp\_>** Do people like using weblate?
**\<ErCiccione>** As far as i can see, they seem to love it
**\<ErCiccione>** and i agree
**\<ErCiccione>** after the release we will use it for the website as well, i don't know if i already said that
**\<xmrscott[m]>** Very much so
**\<sgp\_>** thanks
**\<xmrscott[m]>** Grammatical checks and similar strings os incredibly powerful, and you don't need to find your own locally run client for those features, all browser based
**\<sgp\_>** I'm glad people like the system. It will help make translations more approachable to people who want to help
**\<xmrscott[m]>** We should add MyMonero app at some point too
**\<ErCiccione>** xmrscott: today i added some more QT specific checks, should be even more accurate now
**\<xmrscott[m]>** And as an aside to highlight how amazing it is, when I got the OpenWrt to start using it they described it as very addictive :)
**\<ErCiccione>** about the workflow: i'm roughly using the "continuous translations" system weblate suggests https://docs.weblate.org/en/weblate-2.8/admin/continuous.html
**\<xmrscott[m]>** My person favorite feature is the ability to get new emails when new strings are added
**\<ErCiccione>** yeah the notification system can be personalized a lot
**\<sgp\_>** Any other localization comments?
**\<el00ruobuob\_[m]>** i just saw that, that's great!
**\<sgp\_>** c. GUI workgroup
**\<sgp\_>** GUI code freeze is today. i2p support will come in a later point release unfortunately
**\<sgp\_>** the complexity of the code took a toll on some contributors who need more time to make it happen
**\<sgp\_>** related note: dsc has been teasing a new non-core GUI that he made on the side
**\<sgp\_>** Any questions? I'll do my best to answer
**\<rottensox>** na. move on.
**\<needmonero90>** I believe there was some discussion on renaming the GUI?
**\<needmonero90>** idk where that went
**\<needmonero90>** some people thought "Monero GUI" was too clinical/technical, and wanted something "warmer" for new users (my words)
**\<sgp\_>** needmonero90: I'm going to table that discussion for this meeting, but here is the relevant naming discussion that xmrscott[m] is championing: https://github.com/monero-project/meta/issues/384
**\<thunderosa>** I'll just chime in with wanting to banish anything "graphical interface" because the public has never seen a non-graphical interface.
**\<needmonero90>** wasn't trying to discuss it, just find the discussion point :)
**\<thunderosa>** It's inside reality vs outside reality.
**\<sgp\_>** no problem, thanks for mentioning
**\<sgp\_>** is sarang free to do a quick MRL update?
**\<sgp\_>** d. Monero Research Lab
**\<sgp\_>** Surae made significant progress on his matching code, with preliminary results now available for validation. Sarang did some hard moon math. Their meeting logs are on Github under meta.
**\<sgp\_>** We also discussed subaddress association (and the related Janus attack). See this article and the accompanying Breaking Monero episode: https://getmonero.org/2019/10/18/subaddress-janus.html
**\<sgp\_>** if there are no other comments or questions, we can move on to 5
**\<sgp\_>** 5. Monero 0.15 release name
**\<sgp\_>** We need to pick a release name. To assist this, I’ve solicited feedback informally in this ranked-choice poll: https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E\_e228920d8a4d1cec&akey=ebaf2172a4c2dcc9
**\<sgp\_>** Results:
**\<sgp\_>** 1. Carbon Callisto
**\<sgp\_>** 2. Carbon Comet
**\<sgp\_>** 3. Carbon Crab
**\<sgp\_>** 4. Carbon Chamaeleon (or Chameleon)
**\<sgp\_>** 5. Carbon Cosmos
**\<sgp\_>** at this point we really need to pick a name, fast
**\<needmonero90>** I'll do a quick Telegram poll
**\<thunderosa>** Callisto is already the name of a crypto-project. Comet or Cosmos are both strong
**\<needmonero90>** speaking of projects with the same name, cosmos?
**\<needmonero90>** lol
**\<sgp\_>** I shared this on Telegram too needmonero90, but other feedback is welcome. You can point them to the same link if you like. I can keep it up for the rest of the day
**\<thunderosa>** well, it's a little more universal I guess
**\<darkaleph>** callisto is a little on the nose as well
**\<rottensox>** Carbon Comet is a winner.
**\<needmonero90>** crab too :(
**\<sgp\_>** I'm fine with all 5 of those choices honestly
**\<needmonero90>** though lots of elements have a C, so
**\<sgp\_>** crab is probably my least favorite though
**\<hyc>** I dislike COmmet / Consetllation /whatever as too generic
**\<thunderosa>** yeah, crab = bad
**\<needmonero90>** D:\<
**\<needmonero90>** how dare you
**\<needmonero90>** I'll fork off
**\<hyc>** the name should be a specific celestial body, not a general type of object
**\<sgp\_>** lol sorry :p
**\<needmonero90>** crab nebula\*
**\<needmonero90>** btw
**\<sgp\_>** "MASSIVE Monero naming dispute"
**\<hyc>** So Callisto, Crab, Chamaeleon are the only proper nouns in this selection
**\<thunderosa>** Cassiopeia
**\<el00ruobuob\_[m]>** Luna wasn't a specific celestial body hyc
**\<hyc>** yes it is Luna is a proper name for the earth's moon
**\<sgp\_>** hyc: I interpret the naming convention a little more loosely, so I'm ok with any of these if they make sense
**\<sgp\_>** in some ways, the simplicity is a strength
**\<rottensox>** luna is moon in Spanish
**\<rottensox>** yeah, i'll see myself out.
**\<rottensox>** Carbon Comet dammit.
**\<sarang>** Sorry I stepped away for a moment
**\<needmonero90>** \\o/
**\<needmonero90>** welcome back
**\<sgp\_>** Carbon Callisto is both simple and unique enough that it's a reasonable compromise imo
**\<sarang>** Hit a bump in a soundness proof
**\<sarang>** I'm working on alternate approaches
**\<needmonero90>** sgp\_: https://coinmarketcap.com/currencies/callisto-network/
**\<thunderosa>** Yeah, and it's a bullshit coin too.
**\<needmonero90>** at rank 694 we'd trounce their SEO, so its nbd
**\<sgp\_>** yeah I'm not too concerned about that :p
**\<needmonero90>** after looking at it, I think using Callisto isn't a problem, even though its another crypto project
**\<needmonero90>** my concerns are gone now
**\<needmonero90>** https://coinmarketcap.com/currencies/cosmos/
**\<needmonero90>** that tho
**\<needmonero90>** cosmos is out
**\<sgp\_>** yeah, probably not the best idea
**\<el00ruobuob\_[m]>** Carbon Crommelin Comet, abreviated in Carbon Comet ?
**\<el00ruobuob\_[m]>** https://en.wikipedia.org/wiki/27P/Crommelin
**\<monerobux>** [WIKIPEDIA] 27P/Crommelin | "Comet Crommelin, also known as Comet Pons-Coggia-Winnecke-Forbes, is a periodic comet with an orbital period of almost 28 years. It fits the classical definition of a Halley-type comet with (20 years \< period \< 200 years). It is named after the British astronomer Andrew C. D. Crommelin who calculated..."
**\<sgp\_>** Does anyone hate Carbon Callisto?
**\<needmonero90>** the name doesnt conjure up strong feelings of space in my mind
**\<hyc>** I'm ok with Callisto
**\<needmonero90>** but I'm indifferent
**\<sgp\_>** two voters who actually ranked everything in the poll rated it pretty low
**\<thunderosa>** I've got a bad association, but it's probably personal...I'm ok.
**\<sgp\_>** but for most people, it was the top 1-4 choices
**\<hyc>** well, I recognize it as a moon of Jupiter so that works for me. but not much in love with it
**\<needmonero90>** if we go with Comet, I can see some retro cleaning product advertisement pushes by outreach
**\<hyc>** Chamaeleon is still my #1. multiple people pointed out its self-changing nature
**\<needmonero90>** https://i.pinimg.com/originals/3c/34/2b/3c342b122549bade835eaa0fcdc906f2.jpg
**\<needmonero90>** "with ring signatures"
**\<thunderosa>** yeah, chamaleon is a decent choice,...it has some personality
**\<ErCiccione>** i like Callisto
**\<sgp\_>** The Chamaeleon / Chameleon similarities is a small weakness imo. Would be better if they were spelled the same way
**\<needmonero90>** I have a solution
**\<sgp\_>** lol @ comet ad needmonero90
**\<needmonero90>** lets call it Carbon Chamæleon
**\<sgp\_>** lol
**\<needmonero90>** fixes all the issues :D
**\<hyc>** ok with me. alternate spellings, easier spelling, whatever
**\<thunderosa>** +1 Carbon Chamaleon (or however it's spelled)
**\<sgp\_>** well, hopefully this helps Core in some way make a decision :)
**\<needmonero90>** lets table the bikeshedding, debruyne and I will figure out a reddit thread and stuff
**\<darkaleph>** chameleon is better then callisto but if you want heavenly bodies with a nod to rings then Cassini is cool
**\<sgp\_>** we should move on to the final main topic
**\<needmonero90>** nah, move back sgp
**\<needmonero90>** sarang is here now
**\<sgp\_>** sure, sarang do you have a quick summary?
**\<needmonero90>** maybe he's afk again :(
**\<sgp\_>** lol
**\<sgp\_>** he can take the stage if he comes back
**\<sgp\_>** 6. Extracurricular activities
**\<sgp\_>** Rehrar asked to reserve some time for extracurricular activities. Fun things that we can do to help foster the community.
**\<sgp\_>** We tried a gaming session that was a good start, but it wasn't too fun for viewers
**\<sgp\_>** We still have some room to test things out there I think
**\<sgp\_>** I recently paid for a premium Kahoot subscription for r/cryptocurrency, so we can use that for fun quizzes if we want
**\<sgp\_>** but ultimately, what activites would be useful to help bond the community together? what would you like to see the Monero community do?
**\<rottensox>** videogames, sports, even board games tournaments. put together by the community for the community and its users...
**\<sgp\_>** board games are cool, but they're a little difficult to play online
**\<rottensox>** livestreaming community members playing a videogame won't do much.
**\<hyc>** this community isn't collected together because of gaming
**\<sgp\_>** we probably need an announcer for the games
**\<sgp\_>** hyc: of course not, but we're looking for other excuses to do things
**\<rottensox>** well, I precisely said board games to do them face to face...
**\<rottensox>** gaming can help others understand a truckload of things. through gaming you can achieve many things...
**\<thunderosa>** I don't really like it, but gambling type stuff has been popular. Maybe that could be made to be more interactive or team-based or something.
**\<rottensox>** there's a lot of room for us to grow. ruling out games be it videogames, board games, sports or anything you can think of is very short-sighted.
**\<hyc>** sure. maybe you can try putting together an educational game about monero, money, finance...
**\<sgp\_>** cooperative minko lol
**\<rottensox>** a little guy created moneropoly...
**\<sgp\_>** I wonder if that could somehow be done as a giveaway instead of gambling like it was done at Defcon
**\<rottensox>** a tournament of moneropoly? :-)
**\<sgp\_>** but I wonder how much appeal that has
**\<el00ruobuob\_[m]>** i'm in for a moneropolly tournament
**\<rottensox>** a set of cards whose arts are xmr-related?
**\<thunderosa>** monopoly actually kinda words online,..more than most other games at least
**\<rottensox>** see? there we go. interest spiking.
**\<needmonero90>** hyc: corporations aren't collected together because of golf, but its still a fantastic excuse to do something outside of a business context in a more casual situation
**\<rottensox>** thunderosa: you have not played moneropoly, have you?
**\<needmonero90>** for example.
**\<thunderosa>** no, I saw the post and thought it was a cool. I'm a Monopoly hound from way back.
**\<sgp\_>** A Monero-themed cards against humanity could maybe work, but I think the websites that support custom cards are really dated
**\<hyc>** you could do moneropoly with live wallets
**\<hyc>** on testnet coins
**\<needmonero90>** finally my testnet hoard will be useful
**\<sarang>** Gah, i am back!
**\<thunderosa>** well, just a $1 buy-in to play,....the pot gets split somehow with the winner and the house
**\<sarang>** Multitasking is failing me
**\<thunderosa>** goes to the fund or something
**\<sgp\_>** Can we somehow make "Game of Whales" work? Somehow related to Game of Thrones
**\<needmonero90>** more like unitasking
**\<needmonero90>** sarang whats the summary?
**\<rottensox>** outreach and rehrar can help these idea pan out?
**\<needmonero90>** sgp\_: Lets discuss game stuff unlogged after-meeting :)
**\<sarang>** I have been hard at work on a new transaction protocol
**\<rottensox>** s/idea/ideas
**\<monerobux>** rottensox meant to say: outreach and rehrar can help these ideas pan out?
**\<sgp\_>** sure needmonero90. good to get some ideas rolling while people are paying attention
**\<sarang>** A really cool multi input version works but the soundness proof does not
**\<sarang>** A single input version does have proofs that are working
**\<sarang>** But I would love to get the former proven properly
**\<sarang>** It's so close
**\<sarang>** I have a full writeup to share at Mondays meeting
**\<needmonero90>** anything happening on the other protocol fronts?
**\<needmonero90>** Halo, RCT3, lelantus?
**\<needmonero90>** or are those same as before
**\<sarang>** I want to backport some RCT3 stuff for efficiency comparisons
**\<sarang>** Nothing new on Omniring given its batch limitations
**\<sarang>** The RCT3 stuff was on hold due to this new protocol
**\<sarang>** So much math to do!
**\<rottensox>** sounds right up your alley though.
**\<sgp\_>** Thanks sarang!
**\<sgp\_>** Any final comments before we wrap up the meeting?
**\<sgp\_>** Thanks for joining everyone
**\<sgp\_>** (skipping 7. open ideas time)
**\<el00ruobuob\_[m]>** thank you!
**\<msvb-mob>** Thanks sgp\_, good meeting.
**\<sgp\_>** 8. Confirm next meeting date/time
**\<sgp\_>** The next community meeting will be in 2 weeks on 9 November at 17:00 UTC. Note a possible regional time change! The next Coffee Chat will be on 16 November at 16:00 UTC, but we may change the format. Stay tuned for more details.
**\<sgp\_>** 9. 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.