Verified Commit b6fff2cb authored by el00ruobuob's avatar el00ruobuob
Browse files

Meeting logs for October

parent 75adcbd4
---
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
---
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
---
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
---
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.
---
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