diff --git a/_posts/2017-10-09-logs-for-the-Monero-Research-Lab-meeting-held-on-2017-10-09.md b/_posts/2017-10-09-logs-for-the-Monero-Research-Lab-meeting-held-on-2017-10-09.md
new file mode 100644
index 0000000000000000000000000000000000000000..39f281380ca298041d771fde8c381d6b50478d6c
--- /dev/null
+++ b/_posts/2017-10-09-logs-for-the-Monero-Research-Lab-meeting-held-on-2017-10-09.md
@@ -0,0 +1,136 @@
+---
+layout: post
+title: Logs for the Monero Research Lab Meeting Held on 2017-10-09
+summary: Announcements, Round table discussion of projects, and miscellaneous
+tags: [community, crypto, research]
+author: el00ruobuob / surae
+---
+
+# Logs
+
+**\<surae>** Okay, everyone, welcome to our first MRL Research meeting!
+**\<endogenic>** yay!
+**\<surae>** Agenda, I guess, will be 1) Greetings, 2) Announcements, 3) Round table discussion of projects, 4) anything else that anyone else can think of
+**\<surae>** So, greetings!
+**\<hyc>** hello
+**\<surae>** As far as announcements go, I'll start with the usual: Next week at this time, we'll have office hours, where people can come in and just ask whatever questions they like. Monday 17:00 UTC. Then we'll be alternating Mondays
+**\<surae>** between research meetings and "office hours"
+**\<surae>** i can't think of any other announcements...
+**\<surae>** sarang? anything?
+**\<surae>** Okay, moving along I guess
+**\<surae>** For project discussion...
+**\<surae>** Personally, I've been working on multisig. Sarang and I had some basic security definitions nailed down when he came out to visit. Unfortunately, a paper that mustn't be ignored came out by Boneh and co-authors...
+**\<surae>** https://eprint.iacr.org/2017/956.pdf
+**\<surae>** That paper presents a new scheme that is not directly relevant to us (although it may be in the future) but importantly it defines several security models
+**\<endogenic>** How lucky it came out at the same time...?
+**\<endogenic>** ;)
+**\<surae>** one of the security definitions Sarang and I came up with is actually a stronger definition than the one in that paper
+**\<endogenic>** Of course
+**\<surae>** so, it seems as if we are on the right track, if someone like Boneh is thinking about similar problems
+**\<surae>** There are some implementation issues in my description also; the current draft is here: https://www.sharelatex.com/project/5980a44556789660b0600edb
+**\<hyc>** sounds like their paper is applicable both to multisig and the ever-popular trusted setup
+**\<sarang>** Sorry here
+**\<surae>** hyc tbh i haven't gotten deep into their homomorphic-specific stuff, so i have very little idea. i'm very interested in their security definitions, though
+**\<surae>** welcome~
+**\<endogenic>** Should we mention ppl like mooo at the beginning of mtgs?
+**\<surae>** oh good idea
+**\<endogenic>** Per multisig
+**\<surae>** moneromooo knaccc luigi1111 fluffypony anonimal dEBRUYNE
+**\<sarang>** So yes multisig is coming along well
+**\<sarang>** Subaddress paper is done
+**\<sarang>** That was posted as a final draft to the channel for comment
+**\<sarang>** And is ready to go to Reddit etc
+**\<surae>** yes, Subaddress paper will now be MRL-0006, will be pushed to my github in a bit here and then i'll issue a pull request to the monero-project
+**\<surae>** send us a link real quick sarang
+**\<surae>** i'd be happy to have folks read over it one more time
+**\<surae>** is anyone else doing anything research-y? learn something new? anyone working on a project?
+**\<sarang>** https://github.com/b-g-goodell/research-lab/blob/master/publications/bulletins/in-prog/MRL-9999-subaddy/MRL-9999-subaddresses.pdf
+**\<sarang>** I am updating myself on some aggregator constructions
+**\<sarang>** And based on the Green tweet, I'd like us to do an analysis of our use of PRNGs
+**\<hyc>** I have nothing crypto-related to offer. been benchmarking DB engines lately. (LMDB still fastest.)
+**\<surae>** i'd be very interested in hearing from xpto also, since he's working on some LN stuff, and anonimal, since he's dealing with RSA I guess for kovri? knaccc is probably catching up in his RL from spending weeks programming RuffCT/StringCT/RTRS RIngCT
+**\<surae>** hyc can you link me a primer for LMDB? i know precisely zero
+**\<hyc>** https://symas.com/lmdb/technical/#pubs
+**\<surae>** nice thanks
+**\<endogenic>** i've been curious if there's a simpler implementation of i2p possible
+**\<endogenic>** and i'm just wondering (blindly) about revocable view keys
+**\<surae>** i am excited to start thinking about those more deeply. multisig is...
+**\<hyc>** ah, the notion of time-limited/expiring view keys sounds like a good idea
+**\<moneromooo>** Sorry, I was out.
+**\<surae>** yes
+**\<surae>** no problem mooo, i didn't ping anyone before we started (my bad, first time here yuk yuk)
+**\<endogenic>** hyc: i've heard some downsides to proposals of time-expiring view keys
+**\<surae>** multisig is more delicate than i thought. thing is, i'm pretty sure that our current implementation is safe enough to roll with (pending sarang's agreement, maybe). problems abound, though
+**\<endogenic>** nm90 had some concrete ideas on it
+**\<endogenic>** problems?
+**\<surae>** the problems aren't huge. it's like "well, if an adversary uses a side channel attack and listens in on this computation here, the adversary may be able to determine whether a certain key is a shared key or not, so these here should be communicated with encryption" and so on and so forth. since the security of keys in that way is far less important than being unable to go backwards and determine the
+**\<surae>** participating private keys, stuff like this isn't a huge deal
+**\<surae>** little... details. that keep building up.
+**\<surae>** so, i'm going to take a day or two off of it and work on other things, to reset my brain. it's been a few days of just multisig. Pending sarang's agreement on the multisig code being "safe enough," multisig can be put to work before the MRL-0007 paper is put out, though. Two reasons for this
+**\<sarang>** A lot of it is about assuming things about communication of coalition members
+**\<surae>** First, even if multisig satisfies weaker security definitions than i would like, we can always push changes to it later. Second, I'm already proposing a slightly different implementation in the paper than we are currently going to see in the code. I'm considering writing an appendix to this paper that compares the current code by moneromooo with my suggested implementation, and attempts to close the gap
+**\<surae>** between them.
+**\<surae>** so, anyway, i'll probably take two days off and think about blockchains or specter or difficulty or something
+**\<sarang>** Now what about this PRNG bizniss?
+**\<moneromooo>** Monero's PRNG is not homebrew, AFAIK it's the canonical construction from the Keccak authors.
+**\<surae>** ?
+**\<surae>** Our PRNG should follow whatever the best practice is. I'm not convinced NIST or ISO are the ones who describe the best practices. maybe we should have our own standard for that
+**\<sarang>** I'd like to understand it a bit better
+**\<sarang>** Especially since the issue was raised last year and kinda died away
+**\<surae>** either way, identifying where the PRNG as-is currently influences stuff that actually hits the blockchain seems to be a no-brainer sort of thing to do anyway
+**\<hyc>** https://www.deepdyve.com/lp/institute-of-electrical-and-electronics-engineers/software-only-extremely-compact-keccak-based-secure-prng-on-arm-cortex-QsZRJs71MZ
+**\<surae>** I also want to vet this spectre paper. I'm suspicious of outlandish claims.
+**\<surae>** Thanks hyc
+**\<hyc>** also https://keccak.team/files/SpongePRNG.pdf
+**\<hyc>** afaics it's already heavily studied
+**\<surae>** that's interesting. i'd be very interested to have a conversation with Green
+**\<surae>** maybe i'll shoot him an e-mail
+**\<surae>** i also want to meet an economist
+**\<endogenic>** ArticMine might be able to help you there surae
+**\<surae>** for ASIC and POW discussions. i need to learn about the game theoretic dynamics behind commoditizing hardware, decentralization, renting, etc
+**\<surae>** nice
+**\<surae>** Okay, so in the next two weeks: progress on multisig expected, i want to vet the spectre paper, sarang is learning about accumulators lacking a trusted set-up, hyc will presumably continue playing with DB engines
+**\<hyc>** ;)
+**\<endogenic>** surae will take a short vacation
+**\<surae>** Oh
+**\<endogenic>** ... right??
+**\<sarang>** Aye
+**\<surae>** actually, yes, i need sleep and it just snowed for the first time
+**\<surae>** i need a weekend
+**\<surae>** hard to separate work and life
+**\<sarang>** Other issues of interest?
+**\<surae>** oh, and since we are having this public discussion right now
+**\<surae>** RTRS RingCT: we've concluded that pretty much any improvement in signature verification time will lead to exponentially bigger rings for the same blockchain size.
+**\<surae>** on the flip side: any increase in verification time will lead to exponentially smaller rings
+**\<surae>** this is a property of any logarithmically sized ring sig scheme
+**\<hyc>** "lead to bigger" -> "enables using bigger" ?
+**\<surae>** yeah, for the same blockchain size
+**\<hyc>** ok
+**\<surae>** since RTRS RIngCT is log-sized and has comparable verification time compared to MLSAG, it's not feasible to implement them unless we can make them faster to verify than MLSAG. If they are as fast or slower, they aren't worth switching to
+**\<surae>** and i believe vtnerd benchmarked sandy2x and it was freaking fast
+**\<hyc>** faster than MLSAG?
+**\<surae>** well, sandy2x is just an EC arithmetic implementation
+**\<surae>** so boht MSLAG and RTRS RingCT would be faster
+**\<hyc>** ok
+**\<surae>** i believe he got around a 15% improvement in EC arithmetic time, which would lead to around 15% faster verifciation time
+**\<surae>** which would allow us to have a fixed min ring size of 10!
+**\<surae>** not 10 factorial
+**\<surae>** but 10
+**\<surae>** we could possibly even get away with a ring size closer to 32 or something like that
+**\<hyc>** so RTRS RingCT is still viable, not dead. good to know
+**\<surae>** now, knaccc had me contact some folks who did some GPU otpimization for EC
+**\<surae>** and their code also speeds up CPUs because it's so optimized
+**\<surae>** for Curve25519
+**\<surae>** they are eager to help us try to impement it, though, their emails show a lot of enthusiasm, and I didn't even ask for assistance or anything
+**\<surae>** so, i'm going to pursue that further in the next two weeks also
+**\<hyc>** excellent
+**\<surae>** i kind of wanted all that "on the record" so to speak
+**\<surae>** I can't think of anything else for now.
+**\<surae>** sarang, anything?
+**\<sarang>** Negatory
+**\<surae>** allrighty, well
+**\<sarang>** Keep up the good fight?
+**\<surae>** yep
+**\<sarang>** We can talk PRNG after
+**\<surae>** and if anyone reads any papers on forward-secure key exchange that may be helpful for revocable view keys, send them along!
+**\<surae>** yep, we can call this meeting \*over \*
diff --git a/_posts/2017-12-18-logs-for-the-Monero-Research-Lab-meeting-held-on-2017-12-18.md b/_posts/2017-12-18-logs-for-the-Monero-Research-Lab-meeting-held-on-2017-12-18.md
new file mode 100644
index 0000000000000000000000000000000000000000..0121fb0fb2c5185a9bb83ba0a71795637424476d
--- /dev/null
+++ b/_posts/2017-12-18-logs-for-the-Monero-Research-Lab-meeting-held-on-2017-12-18.md
@@ -0,0 +1,83 @@
+---
+layout: post
+title: Logs for the Monero Research Lab Meeting Held on 2017-12-18
+summary: MRL work, MRL 2018 forecast, and miscellaneous
+tags: [community, crypto, research]
+author: el00ruobuob / surae
+---
+
+# Logs
+
+**\<suraeNoether>** okay, everyone, I suppose we can start this research meeting
+**\<suraeNoether>** 1) Greetings, 2) What has everyone been doing? 3) What should 2018 look like for MRL, in your opinion?
+**\<andytoshi>** btw if i got a reviewer to look at the bp stuff (hypothetically) who wolud i ping about security issues
+**\<suraeNoether>** andytoshi: I think sarang
+**\<moneromooo>** And luigi1111w.
+**\<suraeNoether>** luigi1111w and moneromooo would also be good contacts
+**\<suraeNoether>** \*nod\*
+**\<suraeNoether>** So, hi everyone. sarang anonimal ArticMine dEBRUYNE endogenic gingeropolous JollyMort[m] pigeons othe silur stoffu unknownids vtnerd waxwing
+**\<suraeNoether>** I know sarang is moving so he may or may not be active this morning
+**\<suraeNoether>** Sarang and I are finishing up the multisig paper and then we'll be shopping it around to get thoughts from community members
+**\<sarang>** Hello
+**\<suraeNoether>** howdy~
+**\<sarang>** andytoshi: yeah any reviews could contact me
+**\<suraeNoether>** We have also been reading about the new untrusted-set-up zk-snark paper. I'm particularly interested to see if BPs can be dropped into that scheme.
+**\<sarang>** sarang.noether@protonmail.com is a good way to contact more privately
+**\<silur>** or darkwire.io for realtime
+**\<sarang>** suraeNoether: yes, there is a particular inner-product argument they use
+**\<silur>** surae you talking about hyrax?
+**\<sarang>** yes
+**\<suraeNoether>** silur yes
+**\<silur>** I will most likely be responsible for ZoKRates implementation
+**\<suraeNoether>** oh, at ethereum?
+**\<silur>** chris and vitalik seem to be too concerned about scalability
+**\<silur>** yea
+**\<silur>** but IMO hyrax witness size etc totally worth for kicking trusted setups
+**\<sarang>** It's certainly worth our looking into
+**\<sarang>** And I've found the paper to be quite good
+**\<sarang>** very solid lit review too
+**\<silur>** it's amazing
+**\<suraeNoether>** I don't care so much about sizes, I care more about validation times under the conditions we've been considering recently
+**\<sarang>** They explicitly consider validation complexity
+**\<suraeNoether>** yep
+**\<sarang>** which is a welcome addition
+**\<silur>** well hyrax is highly parallel
+**\<sarang>** mhmm
+**\<silur>** should be many times faster on first sight then simple Groth
+**\<sarang>** Very dependent on circuit parallelization
+**\<silur>** but haven't actually made any tests on that
+**\<silur>** I also got my attention on this
+**\<silur>** http://arxiv.org/abs/1712.04417v2
+**\<silur>** quite relevant on sharding, decentralized storage etc
+**\<sarang>** oh interesting
+**\<suraeNoether>** In addition to the authentication end of things, Sarang and I have also been working on an implementation of SPECTRE, the blockchain concencus algorithm here: https://eprint.iacr.org/2016/1159.pdf
+**\<sarang>** Yeah, constant time implementation of SPECTRE is quite interesting
+**\<silur>** wow
+**\<sarang>** Hinted at by the authors but not explicitly considered in the paper
+**\<suraeNoether>** My current constant-time implementation is on my github here https://github.com/b-g-goodell/research-lab/tree/in-prep/source-code/Spectre <--- it does not match the current SPECTRE algorithm so that it can operate in constant-time, but there are also some design choices I'm tinkering with in the original SPECTRE algorithm...
+**\<suraeNoether>** and, it doesn't pass unit tests yet (with or without the aforementioned tinkering)
+**\<suraeNoether>** but this appears to be the first implementation of spectre anywhere
+**\<sarang>** The unit tests are tricky with this
+**\<sarang>** Because the voting gets so complex very quickly
+**\<sarang>** and suraeNoether you found it doesn't always match intuition
+**\<suraeNoether>** Spectre uses insanely high block arrival rates, so I've been doing computations to maximize privacy (ring size) and transaction processing rate subject to a constraint of getting some minimum gain in new node sync time.
+**\<suraeNoether>** i plan on using values from RTRS ringCT (or RuffCT), MLSAG signatures, borromean range proofs, and bulletproofs to determine what sort of rates we could rationally use in spectre while maintaining network security. I wouldn't mind throwing the new zk-snarks in there also
+**\<suraeNoether>** I've also attained some recent proofs into why some ideas I was previously researching just fundamentally aren't going to work
+**\<suraeNoether>** for example, in terms of Proof-of-Space, I am giving up the ghost for a few months or more, because one critical property of block validation is that it can't have \*progress\* like a progress bar. otherwise, the fastest/strongest always wins the next block.
+**\<suraeNoether>** and i think that PoS will tend toward a progress-bar-like block validation mechanism
+**\<suraeNoether>** a few other ideas I had can't work like that
+**\<suraeNoether>** i'm literally thinking of writing a blog post entitled "Apparently clever but inarbuably bad ideas for cryptocurrencies."
+**\<suraeNoether>** silur keep us informed on how Zokrates comes along
+**\<suraeNoether>** anyone else doing anything interesting?
+**\<sarang>** I'm enjoying zkSNARKs and SPECTRE and tweaks to BP efficiency and review
+**\<sarang>** and helping out w/ multisig review, which has gone well
+**\<sarang>** I'm moving this week and trying to balance that as well
+**\<suraeNoether>** Allrighty for 3) a few things. Firstly, i think we are going to follow the cue of #monero-dev meetings and postpone our next meeting. I'm going to say Monday Jan 8 (perhaps Mon the 1st is cruel). Secondly, for research meetings each week, perhaps sarang or I can present a paper we had read the previous week and try to describe how it works to the community.
+**\<sarang>** Ha just like a real lab group meting
+**\<suraeNoether>** ikr
+**\<suraeNoether>** but moreover
+**\<suraeNoether>** I want to know how everyone feels about the direction MRL should head in 2018
+**\<sarang>** As long as it doesn't turn into a Buzz Killington event: https://www.memecreator.org/static/images/memes/4440318.jpg
+**\<suraeNoether>** eh, this conversation could wait until our next meeting, I think.
+**\<unknownids>** ooo lab group https://i.imgur.com/ehgxi9o.png
+**\<suraeNoether>** oh man it's meme time, meeting adjourned ~ hehe
diff --git a/_posts/2018-12-03-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-03.md b/_posts/2018-12-03-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-03.md
new file mode 100644
index 0000000000000000000000000000000000000000..0e0dd0e9f5edd9f447c2b88848bfda266adfc330
--- /dev/null
+++ b/_posts/2018-12-03-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-03.md
@@ -0,0 +1,181 @@
+---
+layout: post
+title: Logs for the Monero Research Lab Meeting Held on 2018-12-03
+summary: Surae work, Sarang work, and miscellaneous
+tags: [community, crypto, research]
+author: el00ruobuob / sarang
+---
+
+# Logs
+
+**\<sarang>** OK, it's time to begin our meeting
+**\<sarang>** ping suraeNoether and others (mass ping sucks)
+**\<endogenic>** i am self-pinging
+**\<serhack>** ping serhack
+**\<serhack>** Hey!
+**\<suraeNoether>** howdy everyone
+**\<sarang>** If everyone pings three others, eventually the whole world is pinged
+**\<sarang>** pinged? pung?
+**\<suraeNoether>** multi-level pinging schemes
+**\<suraeNoether>** consider myself punged
+**\<sarang>** definitely pung
+**\<suraeNoether>** it's like the purge, but pingier
+**\<endogenic>** pang\*
+**\<sarang>** I have several items on my provisional agenda today, as well as a round-the-horn to see what folks wish to share
+**\<sarang>** First, the Lab landing page https://getmonero.org/resources/research-lab/ has been updated to add new papers
+**\<endogenic>** very nice!
+**\<sarang>** translations are welcome, now that we support them
+**\<sarang>** I only added English abstracts
+**\<sarang>** Second, suraeNoether and I will be posting new FFS requests for Q1 2019 shortly
+**\<sarang>** We've been discussing, as we often to, the correct way to assess the amount
+**\<sarang>** This ties in with discussions elsewhere about how best to approach multi-month funding on FFS
+**\<serhack>** Whoa, translating abstracts to Italian? it would a pleasure for me
+**\<sarang>** serhack: yass
+**\<suraeNoether>** Given the 50% contraction each of the past two quarters, we are trying to decide the best way to price our next quarters. whether we should switch to monthly funding, etc.
+**\<sarang>** The current FFS system doesn't allow for non-escrow payments, so we're stuck with whatever the market does
+**\<sarang>** I've been traditionally using a 14-day EMA or 30-day EMA
+**\<suraeNoether>** Last time, I tried to take trendline into account and I received some pushback, which is very understandable. so we wanted to open up the discussion to get some ideas.
+**\<sarang>** Yeah, what are the group's thoughts on this?
+**\<sarang>** (We'd be requesting through Mar 2019)
+**\<endogenic>** could you make the question a little more concrete?
+**\<endogenic>** for clarity
+**\<sarang>** We could do shorter periods, like monthly, but that opens to donor fatigue
+**\<sarang>** endogenic: what's the fairest exchange rate computation?
+**\<suraeNoether>** i'm generally opposed to using moving averages: in an uptrend, the community ends up paying more and we receive disproportionately more than \*that\* by the time our paychecks come around... so we are arguably unfairly overcompensated... and in the downtrend, the opposite occurs, where donor cash doesn't go as far, and we still receive disproportionately less than \*that\* by the time our paychecks come around
+**\<endogenic>** imo ideally you all shouldnt have to worry about that as you really want to have your compensation targeted for the currency you have to pay rent, taxes, etc in
+**\<endogenic>** so it's whatever allows you not to have to worry about it
+**\<endogenic>** i think it's a real issue though as a source of stress
+**\<sarang>** Well, discussions of how to structure FFS in the future are good ones, but right now it is what it is
+**\<suraeNoether>** endogenic: what if we list our desired salaries in USD and donating to pay our salaries could be a rolling thing; at the end of each month, we take a 48-hour average or something based on Kraken or whatever, and we dip into that fund according to that instantaneous exchange rate? it seems more fair to both donors and us to use a method like that
+**\<endogenic>** that's interesting
+**\<sarang>** It might encourage donors to delay donations
+**\<sarang>** until they know the actual value being dispersed
+**\<suraeNoether>** that may actually work out to everyone's benefit
+**\<suraeNoether>** people see their XMR hit our account at much closer to their desired exchange rate
+**\<suraeNoether>** or rather, we gain control over it at a more reasonable rate
+**\<sarang>** Any big opposition to investigating this further? We'd need a decision very quickly
+**\<suraeNoether>** so people's money isn't wasted on volatility and we get what we need to pay rent, etc
+**\<suraeNoether>** fluffypony luigi1111w any thoughts?
+**\<sarang>** ping binaryFate or luigi1111 or fluffypony
+**\<suraeNoether>** ArticMine and binaryFate too
+**\<sarang>** jinx
+**\<endogenic>** when atomic pings
+**\<suraeNoether>** cross-client atomic pings via SMS relayed by telegram (the literal wire, not the app)
+**\<suraeNoether>** (not wire the app either)
+**\<endogenic>** make it so
+**\<suraeNoether>** anyway, let's put that on the back burner until we get feedback, hopefully in the next day or so
+**\<sarang>** Anyway, until Core Team arrive, let's move on
+**\<suraeNoether>** yep
+**\<endogenic>** wow are you guys twins or something
+**\<sarang>** suraeNoether: want to give your updates?
+**\<cjd>** https://github.com/cjdelisle/RandomHash
+**\<sarang>** hello
+**\<cjd>** howdy
+**\<cjd>** experimentation on randomized hash function
+**\<suraeNoether>** well, recently I've been working on three things
+**\<suraeNoether>** cjd thanks for the contribution
+**\<suraeNoether>** first thing i've been working on is the matching paper, which i've handed off to sarang
+**\<suraeNoether>** i had some ideas over the weekend on how to quantify some churn length methodology
+**\<suraeNoether>** which is a step in the right direction
+**\<suraeNoether>** the second thing i've been working on is reading more about accumulators and zero knowledge proofs of membership and nonmembership
+**\<suraeNoether>** this is surae. this is surae catching up on large-anon-set-authentication-without-trusted-setups-to-replace-ring signatures. see surae cry.
+**\<binaryFate>** Rolling fund sounds good
+**\<suraeNoether>** binaryFate +1 thanks for the feedback :D
+**\<suraeNoether>** the third thing I've been working on is mapping certain discrete-log-based crypto schemes over into a module-theoretic setting and constructing examples. this is a fun hobby for me that is brand new and sarang and i are going to write a paper on it
+**\<suraeNoether>** i've also been working on non-research stuff related to the monero konferenco, and we just got back from our monero workshop in nashville, where we met up to do some research and brainstorming face to face
+**\<suraeNoether>** oh, and i've been making some final edits to the thring sig paper before submitting for peer review
+**\<suraeNoether>** and that's it
+**\<suraeNoether>** oh, i started reading silur's verifiable shuffle
+**\<sarang>** Any specific questions on suraeNoether's recent work?
+**\<sarang>** going once, twice
+**\<sarang>** OK, I'll make my update
+**\<sarang>** suraeNoether has passed on the current draft of the graph matching paper to me for additional work; this is some really cool shit that will be worth everyone's time
+**\<sarang>** I'm finalizing a tech note on discrete logs, reviewing several other papers by other researchers, and also finishing up some re-review of a ring representation paper from Matt Green's team from a while back
+**\<sarang>** My goal is get the tech note, graph matching paper, etc. out the door as efficiently as possible
+**\<sarang>** I want next quarter to focus more heavily on ringct replacements, as does suraeNoether
+**\<sarang>** Any specific questions for me or for suraeNoether on these fast updates?
+**\<sarang>** chirp chirp
+**\<sarang>** Isthmus was unavailable but wanted me to share the following update (one sec):
+**\<sarang>** https://www.irccloud.com/pastebin/UGzuSz5P/
+**\<sarang>** sgp\_ was looking at pool output data to give more information that could lead to changes in how we handle pool and coinbase outputs
+**\<endogenic>** very cool sgp\_
+**\<sarang>** The upcoming Stanford Blockchain Conference has its free registration open now: https://cyber.stanford.edu/sbc19
+**\<sarang>** Both suraeNoether and I applied to speak, but I have not heard back on this
+**\<sarang>** An FFS to fund our presence was successful, but the market has been... unkind in the meantime
+**\<endogenic>** as it is
+**\<sarang>** Hopefully at least one of us is accepted, to offset those costs. It's an exceptionally worthwhile event
+**\<sarang>** Does anyone else have work of interest to share with the group?
+**\<suraeNoether>** sarang thanks for the link to SBC, i just registered :P
+**\<h4sh3d>** I have worked on an atomic swap BTC/XMR https://github.com/GuggerJoel/XMR-BTC-atomic
+**\<endogenic>** h4sh3d: did you see the feedback you got to that?
+**\<moneromooo>** Worthy goal.
+**\<h4sh3d>** endogenic: I didn't see feedback on IRC
+**\<sarang>** Doesn't that scheme require knowledge of the same scalar across groups?
+**\<endogenic>** h4sh3d: "vtnerd> h4sh3d the paper still has a magic zkp step. How are these values zkp'ed ?"
+**\<sarang>** correct me if wrong
+**\<sarang>** if so, that's a subtle step that is nontrivial
+**\<h4sh3d>** Knowledge of a scalar on ed25519 (i.e. mod l) only
+**\<h4sh3d>** and the SHA256 of the scalar
+**\<sarang>** a proof of that equality in zero knowledge?
+**\<h4sh3d>** that's the magic zkp needed, but with Bulletproofs it is possible to prove these constraints
+**\<sarang>** Yeah, other proposals have had the same issue
+**\<h4sh3d>** > a proof of that equality in zero knowledge?
+**\<h4sh3d>** yes
+**\<suraeNoether>** hey guys i have to go a bit early
+**\<sarang>** np
+**\<suraeNoether>** i'll be on for most of the day
+**\<endogenic>** see you
+**\<h4sh3d>** I started to write a proposal to work on that scheme, what do you think?
+**\<sarang>** h4sh3d: I need to re-read your paper to remind myself of a few details, but does the sender on one chain guarantee return of funds if the protocol fails?
+**\<h4sh3d>** sarang: yes if it fails Alice (XMR) get her XMR back and Bob (BTC) get his BTC baCK
+**\<h4sh3d>** If Bob disappears Alice gains the BTC
+**\<sarang>** High level: why does Alice get her XMR back?
+**\<sarang>** Delayed signing and posting by Bob?
+**\<h4sh3d>** Ok, what do you mean by "fail"? The zkp or after the firsts transactions on-chain?
+**\<sarang>** why not either
+**\<sarang>** Under whatever circumstances Alice is not guaranteed the BTC
+**\<h4sh3d>** If after locking the BTC/XMR on-chain Bob does not follow the protocol anymore
+**\<h4sh3d>** can be because Bob disappear or act malicious
+**\<sarang>** So what transaction is posted to the XMR chain, and why can Alice get her funds back if it's posted and Bob disappears or pulls other shenanigans?
+**\<sarang>** Proposals around refund transactions can take advantage of that new construction, but not with this proposal
+**\<h4sh3d>** In this scheme the first XMR transaction move funds into the address controlled w/ (a,x) private key, where x is half controlled by Alice and half by Bob
+**\<sarang>** OK, if Bob disappears, Alice can recover the key?
+**\<h4sh3d>** no, but she can get the BTC
+**\<sarang>** Does she wait until Bob has posted the BTC transaction before posting the XMR transaction?
+**\<h4sh3d>** so if Bob disappears, Bob loose
+**\<sarang>** (I'm being purposefully socratic to help me understand better)
+**\<h4sh3d>** np
+**\<h4sh3d>** https://github.com/GuggerJoel/XMR-BTC-atomic/blob/master/whitepaper/xmr-btc.pdf
+**\<h4sh3d>** page 4
+**\<sarang>** Yep, I read that. I want to ensure I understand the nature of protocol failure by asking you that question
+**\<h4sh3d>** Yes, Alice waits enough conf before sending XMR tx
+**\<sarang>** OK, and Bob takes advantage of BTC timelock in case of Alice's disappearance
+**\<h4sh3d>** In fact we can say that Alice or Bob will "sell" half of the key in the Bitcoin tx
+**\<h4sh3d>** Yes, exactly
+**\<sarang>** My spidey sense tells me that someone else had a similar idea at some point, but I don't recall specifically
+**\<sarang>** Even so, at face value a neat idea
+**\<sarang>** made possible by bulletproofs (tm)
+**\<sarang>** To what extent is knowledge of the ed25519 scalar as a hash preimage on the BTC chain group-specific?
+**\<h4sh3d>** I've not finished my journey into Bulletproof, but I'm pretty sure that it's feasible with zkp tech today
+**\<sarang>** h4sh3d: yes
+**\<sarang>** bulletproofs can support this
+**\<sarang>** verification isn't trivial and the circuit is ugly
+**\<sarang>** But yeah, any time you're using values across groups, you have to account for how they are used
+**\<h4sh3d>** Not sure that I understand the question about preimage on the BTC chain group-specific
+**\<sarang>** ed25519 != secp256k1
+**\<moneromooo>** None o that goes onto the chain though, right ?
+**\<moneromooo>** (except the tx)
+**\<sarang>** That's my question
+**\<h4sh3d>** Yea I know but the x is not used with secp256k1
+**\<sarang>** I obviously need to do deeper diving onto the guts of hash timelocks
+**\<h4sh3d>** x\_0 or x\_1 is reveal into the unlock script in bitcoin
+**\<rehrar>** sometimes I think you guys just make up words and terms to sound smart
+**\<sarang>** What groups are those scalars in?
+**\<sarang>** Is there any algebraic requirement beyond "throw it into a hash function as a byte string"?
+**\<endogenic>** rehrar: you're not wrong
+**\<h4sh3d>** I dont think so
+**\<sarang>** h4sh3d: if there are no algebraic assumptions on the scalars and it's purely a matter of byte representation, that's one thing
+**\<sarang>** otherwise you'd have to be very careful about crossing groups (we dealt with this recently do a discrete log equality proof across curves)
+**\<sarang>** Anyway, we should continue to discuss this... but does anyone else have a short item to bring up, before we hit the end of our meeting time?
+**\<sarang>** If not, we can adjourn and continue existing discussions
+**\<sarang>** OK, officially adjourned
diff --git a/_posts/2018-12-10-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-10.md b/_posts/2018-12-10-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-10.md
new file mode 100644
index 0000000000000000000000000000000000000000..889f0407226735486fa32812256973c6bc8314fc
--- /dev/null
+++ b/_posts/2018-12-10-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-10.md
@@ -0,0 +1,202 @@
+---
+layout: post
+title: Logs for the Monero Research Lab Meeting Held on 2018-12-10
+summary: Sarang work, and miscellaneous
+tags: [community, crypto, research]
+author: el00ruobuob / sarang
+---
+
+# Logs
+
+**\<sarang>** OK, it's about time to begin our meeting
+**\<sarang>** Greetings to everyone; who's here?
+**\<sgp\_>** hello
+**\<engelmensch\_>** hi
+**\<sarang>** ping binaryFate endogenic gingeropolous hyc Isthmus moneromooo nioc parasew[m] rehrar smooth stoffu etc
+**\<endogenic>** hello
+**\<sarang>** suraeNoether will be away today
+**\<sarang>** First off, updates on recent work
+**\<sarang>** another tech note (MRL-0010) is merged to -site along with several others that now appear
+**\<sarang>** https://getmonero.org/resources/research-lab/
+**\<sarang>** soon lab.getmonero.org will direct there as well
+**\<sarang>** MRL-0011 deals with graph matching and is being finalized
+**\<sarang>** Along those lines, some interesting lit review
+**\<sarang>** An older paper on quantum-resistant accumulators: https://eprint.iacr.org/2017/1154
+**\<sarang>** One on highly expressive accumulator proofs: http://legacydirs.umiacs.umd.edu/~zhangyp/papers/accum.pdf
+**\<sarang>** Publication of a paper we saw as a talk in London, about using nested merkle trees to avoid evil remote nodes: http://legacydirs.umiacs.umd.edu/~zhangyp/papers/accum.pdf
+**\<sarang>** whoops, wrong paste: https://ieeexplore.ieee.org/abstract/document/8406557/
+**\<sarang>** And the paper discussed this morning about cross-chain stats: https://arxiv.org/abs/1812.02808
+**\<hyc>** cool stuff
+**\<sarang>** Besides those, I'm reviewing additional non-published stuff, one of which is an alternate proposal for return addresses
+**\<sarang>** sgp\_ suggested doing a youtube series called Breaking Monero
+**\<sarang>** each short episode would talk about a common method of monero analysis
+**\<engelmensch\_>** to help the DHS ;) ?
+**\<sarang>** heh
+**\<sgp\_>** want me to paste the initial description ideas?
+**\<sarang>** please do sgp\_
+**\<sgp\_>** I didn't update yet with your feedback
+**\<sarang>** that's fine
+**\<sgp\_>** https://www.irccloud.com/pastebin/XI0H2aU9/Breaking%20Monero%20Ideas
+**\<sarang>** I think doing this will speak well to our transparency and get ahead of low-quality research
+**\<sgp\_>** I also think it will help Monero research be more approachable to those who do not idle here all day
+**\<sarang>** Any thoughts after reading this? (Or on my previous statements about lit review and MRL papers?)
+**\<sarang>** ^^
+**\<engelmensch\_>** is there a plan to add paper references to the episodes=
+**\<engelmensch\_>** ?
+**\<sarang>** We could
+**\<sgp\_>** engelmensch\_: good idea. would take preparation, but would be worth it
+**\<sarang>** Eh, or just short episode notes on a corresponding reddit post
+**\<sarang>** Episode 0: A Preprint is Not Peer Review
+**\<sarang>** The thought was to start the series next week
+**\<sarang>** 15 minute-ish episodes, perhaps
+**\<sarang>** informal
+**\<sgp\_>** exactly. keep it pretty short to keep user attention
+**\<sarang>** Anyway, be thinking about ideas and presentation. Consider them a shorter series similar to the Bulletproofs fireside chat that sgp\_ and I did a while back
+**\<sgp\_>** initial timeline is announce next week, create most content in early Jan
+**\<sarang>** ah ok, nvm then
+**\<engelmensch\_>** any plans for video visualisations? that might help a lot to grasp the problem. or else a whiteboard
+**\<sarang>** I misunderstood
+**\<sgp\_>** first intro episode next week
+**\<sgp\_>** yes, will include visualizations
+**\<sarang>** the finest stick figures that paint can offer!
+**\<engelmensch\_>** ;)
+**\<sgp\_>** pretty much
+**\<sarang>** But IMO that's fine
+**\<sarang>** Too much flash and people will accuse you of being up to something
+**\<hyc>** that's quite a list of episodes. looks good
+**\<sarang>** "Here you go, now shut up about chain analysis"
+**\<engelmensch\_>** not flash, but having too many references in you brain might break stuff, so a diagram is quite useful
+**\<sarang>** agreed
+**\<sarang>** On a funding note, FFS for suraeNoether and me have been posted for Q1 2019
+**\<sarang>** and related to this, a rep from the Loki Foundation contacted me and said their group is interested in funding a researcher in fiat
+**\<sarang>** they've offered 15000 USD for this
+**\<sarang>** the escrow system is not set up for this, so any researcher who took them up on this would do so separately from FFS
+**\<sarang>** I'd be interested to know people's thoughts on the idea of having a researcher partly paid by FFS and partly in fiat by this organization
+**\<sgp\_>** up to the individual I suppose
+**\<sarang>** Their original hope was to help out someone new, which would be great if we could find such a person
+**\<sarang>** but they said that given the market and current FFS needs, they'd be open to doing this for me and/or surae
+**\<notmike>** If only such a person existed!
+**\<sarang>** The latter would obviously be a big change
+**\<sarang>** I'm personally open to the idea, provided the community can be assured that there are no extra strings attached to the fiat
+**\<sarang>** and that research directions aren't being influenced
+**\<sarang>** Anyway, those are my updates. Does anyone else have work of interest to share?
+**\<engelmensch\_>** in my opinion it looks the same as other funded researchers contributing to the comunity
+**\<sarang>** Agreed, but community funding carries a certain onus
+**\<notmike>** Any updates on konferenco?
+**\<engelmensch\_>** I try to write up a simulation based security proof for the ringct
+**\<sarang>** suraeNoether has been planning, but I do not know of updates (and he is away for the morning)
+**\<sarang>** engelmensch\_: in what way?
+**\<notmike>** What happened to the coral reef project?
+**\<engelmensch\_>** in a semi-honest model and then hope to GMW compile it to the malicious model
+**\<sarang>** What aspect of ringct?
+**\<endogenic>** notmike how is that remotely appropriate for this channel? does anyone else find notmike disruptive?
+**\<endogenic>** trying to have a meeting here
+**\<engelmensch\_>** I want to show that the commitment do not leak any more information, as an attacker would find out anyway
+**\<notmike>** excuse me endogenic can you take a step back and try to calm down, please
+**\<endogenic>** no
+**\<notmike>** I'm just curious as are many others about where the monero from the FFS is goin
+**\<notmike>** If you haven't noticed this is something many are asking.
+**\<sarang>** we can discuss that shortly if you don't mind
+**\<endogenic>** go ask on reddit then. this is not your personal attention seeking venue
+**\<sarang>** engelmensch\_: the amount commitments?
+**\<notmike>** Nor have I tried to make it that guy. You should really try to calm yourself. :/
+**\<engelmensch\_>** yes the amount commitments and the intermeidate stuff in the single, in my setting also the color commitments
+**\<sarang>** well the commitment itself is a pedersen commitment, not much info gained there
+**\<sarang>** is it something particular to the signature definition you're looking at?
+**\<engelmensch\_>** not sure if I can only reduce the security of my contruction to the current monero
+**\<engelmensch\_>** I use the MLSAG as a blackbox
+**\<sarang>** Interesting
+**\<sarang>** We'll be glad to help as needed
+**\<engelmensch\_>** but for my paper I'd like a formal proof that it's sound and secure. And the best way to do this was via a simulation based proof
+**\<sarang>** notmike: non-research FFS requests are outside of MRL's scope
+**\<engelmensch\_>** at least, that was what a prof told me who is into it
+**\<sarang>** OK
+**\<sarang>** The existing analysis was essentially a 2-D version of the Liu proofs
+**\<engelmensch\_>** yes, I saw this for the MLSAG and just reference it
+**\<notmike>** sarang: well, consider the Loki Foundation's offer. There should be a serious effort to draw in other researchers before any consideration is made of paying present researchers with that cash.
+**\<sarang>** We don't want to spread community donations too thin
+**\<sgp\_>** at the moment even moneromooo's FFS has been open for a few days
+**\<sarang>** If current researchers get fully funded, it makes more sense to investigate someone else
+**\<notmike>** Its not clear that this would happen from bringing in other researchers, or that fully funding present researchers is the best use of the funds.
+**\<sarang>** It's up to donors to decide what to do with their money
+**\<endogenic>** notmike: i am calm. nice try though
+**\<engelmensch\_>** is there a preprint/draft of MRL-0011?
+**\<sarang>** engelmensch\_: privately, yes, but it's not in a state for public release yet
+**\<engelmensch\_>** ok
+**\<sarang>** it needs only a few more days
+**\<sarang>** then will be posted to github and -site
+**\<sarang>** One issue with bringing in other researchers is that most folks with training in this field are employed already, or are grad students
+**\<engelmensch\_>** because we're writing a grant proposal to investigate cross-layer effects of privacy preserving p2p entworks and privacy preserving applications ontop of them
+**\<sarang>** engelmensch\_: this work is purely about graph analysis
+**\<sarang>** I'll be interested to see your simulation work on this engelmensch\_
+**\<sarang>** Any other news or work of interest to share?
+**\<engelmensch\_>** it might be related, as we did some work with DC nets on the p2p layer which also create some sort of anonymity set as the ringsig
+**\<sarang>** hmm ok, let's talk after meeting about details
+**\<engelmensch\_>** sorry if I'm too verbose
+**\<sarang>** no prob
+**\<sarang>** Hmm well it seems the well of information has run dry a bit early today
+**\<sarang>** I suppose we could discuss more about engelmensch\_'s work given the timing
+**\<sarang>** How do you see our analysis complementing the grant proposal?
+**\<engelmensch\_>** by graph analysis I suppose it's tx graph analysis?
+**\<sarang>** Our work is an examination of formalizing ring sigs as graph structures, and examining the computational complexity of proposing spend histories
+**\<sarang>** it also can tie into other heuristics, like the guess-newest output heuristic
+**\<engelmensch\_>** ok, and how does this hold, if you get auxiliary information from the p2p layer?
+**\<sarang>** You can use heuristic information, like output age or presumably probabilities from p2p layer, to optimize your history selection
+**\<sarang>** and for identified outputs, you can simply remove them from the graph altogether as you might expect
+**\<sarang>** none of it is provable, of course, and the complexity is huge
+**\<engelmensch\_>** jup. my effort on provable stuff was only considering 1 tx
+**\<sarang>** Ah ok, this is a more global analysis
+**\<sarang>** but it could be examined for smaller sets
+**\<engelmensch\_>** the idea behind simulation based based sec proofs is that you create an ideal world, where there is e.g. a trusted third party and then you compare the views of different parties to the real ones. And if there is an algorithm which can create the view of an actor without access to it's secrets, it is considered secure
+**\<engelmensch\_>** I'm in the process of understanding how these proofs actually work from: https://eprint.iacr.org/2016/046.pdf
+**\<engelmensch\_>** maybe written down it makes more sense. I'm happy to have a working implementation of it in the meantime from postponing the theory work
+**\<sarang>** Awesome
+**\<sarang>** Well, looks like good work in progress on that analysis
+**\<sarang>** We should have the first graph paper finished in a few days for review
+**\<sarang>** There's definitely room to expand it to a second one as well
+**\<engelmensch\_>** I'm happy to review it
+**\<sarang>** That'd be excellent
+**\<sarang>** I'll post it here when it's a good state
+**\<sarang>** Original plan was to include a broader scope, but we dialed it back a bit and are removing some stuff
+**\<sarang>** surae also has some code relating to it
+**\<engelmensch\_>** cool
+**\<sgp\_>** Side note: I made this post yesterday regarding attackers collecting IP broadcast data by running nodes: https://medium.com/@JEhrenhofer/attacker-collection-of-ip-metadata-27032e736371
+**\<sgp\_>** m2049r got back to me with an estimate gingeropolous: 3183 Monero nodes, 64 of them with port 18089 open, 56 of those on the proper block height
+**\<sarang>** Conclusions?
+**\<sgp\_>** Attackers can run x many nodes to connect to y clients directly, therefore learning more about the transaction broadcast process
+**\<sgp\_>** s/y clients/y other nodes
+**\<engelmensch\_>** yes. there are some modified clients which connect to all possible nodes and do not relay any pending TX to figure out the timings when they receive the tx
+**\<engelmensch\_>** this can be used to deduce the topology
+**\<engelmensch\_>** we plan on running such a node
+**\<engelmensch\_>** it is also useful to get metrics for 0-confirmation clients
+**\<sarang>** sgp\_ had some estimates posted to reddit/twitter based on this
+**\<engelmensch\_>** how long is a good time to wait before you can be sure that a TX will most likely be included in a block
+**\<m2049r>** since each node reports who its connected to, the topology is clear. or what do you mean engelmensch\_ ?
+**\<engelmensch\_>** no. when you collect the timings of when you get a tx from a node, you can infer the latency between nodes. If you do this with planetlab and have low latency to most peers and GPS timestamping, this gives you pretty good latency estimates
+**\<sarang>** the IP information is a good indicator for the importance of i2p/tor routing
+**\<sgp\_>** Yes. For my research, the next step is estimating the impact that server providers can have
+**\<sgp\_>** m2049r is there a way to do an org lookup on these IPs?
+**\<engelmensch\_>** you can use the location ISP database
+**\<engelmensch\_>** that gives you decent results
+**\<engelmensch\_>** http://lite.ip2location.com/
+**\<sgp\_>** Cool, didn't know about this specific service
+**\<engelmensch\_>** I played with it, when I was using zmap to scan 0.0.0.0/0 and knocked on some ports
+**\<engelmensch\_>** it's a nice way to visualise, but should also serve well to track clients
+**\<sarang>** So engelmensch\_ you are more interested in latency-based topology, as opposed to sgp\_'s interest in ip data from nodes?
+**\<sarang>** if I'm understanding the difference properly
+**\<sgp\_>** At the moment I've done no research with latency
+**\<sarang>** right
+**\<engelmensch\_>** we are 2 PhD students, I'm more on the blockchain layer and my colleague is more network oriented, so he leads this direction
+**\<engelmensch\_>** but atm he wants to have a latency graph
+**\<sarang>** engelmensch\_: is your interest more about adversarial data, or about propagation statistics?
+**\<engelmensch\_>** when you have the propagation statistics, you can motivate a lot of research why latency is important. e.g. if you use a DS network to disseminate pending TX (to hide your position) it has to reach all nodes in an appropriate amout of time
+**\<engelmensch\_>** so there are a lot of really good privacy preserving networks, but they normally have n² messages and therefore are unusable
+**\<sgp\_>** fwiw I have a connection here at Minnesota to Professor Hopper, who does Tor latency and bandwidth research iirc. Could be a useful person to talk to
+**\<sgp\_>** https://www-users.cs.umn.edu/~hoppernj/
+**\<engelmensch\_>** I saw a lot of analysis from the guys in sardinia: http://blockchain.unica.it/
+**\<engelmensch\_>** It's getting late in Europe ;) I'll read up later
+**\<sarang>** Thanks for joining engelmensch\_
+**\<engelmensch\_>** thanks for all the input and discussion
+**\<m2049r>** http://lite.ip2location.com/ looks pretty good - is there a catch?
+**\<sarang>** I guess we never formally adjourned, but thanks to everyone for joining
+**\<sarang>** Seems the order of the day is network analysis
diff --git a/_posts/2018-12-17-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-17.md b/_posts/2018-12-17-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-17.md
new file mode 100644
index 0000000000000000000000000000000000000000..f72a85d96b5a19158aece55f2273e5f4bb3cd92a
--- /dev/null
+++ b/_posts/2018-12-17-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-17.md
@@ -0,0 +1,298 @@
+---
+layout: post
+title: Logs for the Monero Research Lab Meeting Held on 2018-12-17
+summary: Sarang work, Surae work, and miscellaneous
+tags: [community, crypto, research]
+author: el00ruobuob / surae
+---
+
+# Logs
+
+**\<suraeNoether>** howdy everyone
+**\<sarang>** heyo
+**\<suraeNoether>** i've been sick all weekend
+**\<suraeNoether>** I'M BACK THO
+**\<suraeNoether>** not really
+**\<suraeNoether>** still exhausted but INCREMENTALLY GETTING BETTER
+**\<sarang>** just like monero
+**\<suraeNoether>** heh
+**\<suraeNoether>** allrighty everyone: as usual, we'll open with questions, then discuss the work we've done the past weeks since our last update
+**\<suraeNoether>** does anyone have any questions before we open up?
+**\<suraeNoether>** okay. cool :) we'll ask for questions as we go
+**\<suraeNoether>** since last we met I received and started reviewing sarang's version of the matching paper, and I attended the coincenter workshop in san fransisco, and I met isthmus in person
+**\<suraeNoether>** i paid for that trip out of pocket to not burden the community, fwiw
+**\<sarang>** Anything more about the coincenter workshop? You had mentioned it a bit before
+**\<suraeNoether>** so, to refresh the audience, coincenter writes policy reports to help inform lawmakers and regulators about cryptocurrency technologies, their true capabilities, and to advocate on behalf of financial privacy, to try to persuade lawmakers to not make stupid decisions
+**\<suraeNoether>** if anyone saw the CFTC commissioner's speech in october: there was a small freakout that the CFTC may be prosecuting developers of smart contracts eventually: these are the sorts of things that coincenter is trying to advocate \*against\*
+**\<suraeNoether>** the reports are extremely well written and contain some of the best arguments, in my mind, that financial privacy is necessary for an open society and that large-scale surveillance of financial transactions is basically antithetical to a free and open society
+**\<sarang>** What did you bring to the table from your perspective?
+**\<suraeNoether>** i brought a few arguments favoring privacy that i like a lot, tbh
+**\<suraeNoether>** for example
+**\<kayront>** clearly preserving financial privacy is a step in the right direction, but how to reconciliate regulator acceptance of something like monero, in a world of guilty by default, aml/kyc, FATCA and CRS? if you were to transpose the banking rules as they stand today to the crypto space, then it seems evident (unfortunately) that the general population having access to the famous swiss bank account in their pocket would go against the
+**\<kayront>** direction of the last decade or two, which is granting government the ability to track anything and everything digital (specifically in regards to money flows in this discussion)
+**\<suraeNoether>** i love it when fluffypony talks about how monero can be used to buy banned books in totalitarian regimes like north korea, for example, because it illustrates that \*using a technology that is morally neutral, and can be used for good or for evil\* is not inherently wrong or criminal, and can be used to do ostensibly "good" things for society
+**\<suraeNoether>** kayront: actually
+**\<suraeNoether>** not to hashtag-actually yoiu
+**\<suraeNoether>** the thing is that the banking rules as they stand today give exhcanges like coinbase plenty of power and ability to comply
+**\<sarang>** Exchanges are waiting for super-conservative Coinbase
+**\<sarang>** I'm not convinced that accepting Zcash was a step in the right direction or not
+**\<suraeNoether>** every single cryptocurrency, zcash and monero included, if you are using KYC/AML exchanges, can totally de-anonymize you. so you may ask a better question which is: "why are law enforcement asking for MORE power and control over this new technology?"
+**\<sarang>** lol because they can
+**\<suraeNoether>** for example kayront
+**\<suraeNoether>** sarang: yeah the answer is obvious
+**\<suraeNoether>** hence the political pushback and advocacy
+**\<suraeNoether>** so, for example kayront, a bank today only needs to file a suspicious activity report about information that's happening inside their own bank
+**\<kayront>** suraeNoether: "totally"? sure, they'll be able to track when you get in and out of monero, but after that, the ship has sailed
+**\<suraeNoether>** the guys at Chase arent' responsible for filing an SAR about stuff that happened on Wells Fargo accounts, and vice versa
+**\<kayront>** transfer to your own wallet, churn as you please for increased peace of mind, do whatever you want
+**\<sarang>** I think he's saying that you give them your name and address and bank info, so of course the exchange knows who you are
+**\<kayront>** i think this sort of thing scares the regulator
+**\<sarang>** Sure it does
+**\<suraeNoether>** so the recent trend where pols and law enforcement officials are asking for additional view key access is in contradiction with their current ability to comply
+**\<suraeNoether>** with classic/traditional assets
+**\<suraeNoether>** if Chase doesn't need to report anything beyond one hop outside their bank, why should Monero give outgoing view key access, for example? stuff like that
+**\<sarang>** We need to convince exchanges that they can already comply
+**\<suraeNoether>** so the coincenter workshop was a day of very smart and stimulating people from various coin projects and various non-profits around the world discussing how to convince lawmakers of stuff like this
+**\<sarang>** but regulators are being super cagey about specifics
+**\<kayront>** i find the whole argument very fallible, so don't misunderstand, of course I don't stand for that .. i don't quite understand how sending money to anyone you want to without asking for permission isn't basically the same as chatting up anyone online as you please without permission
+**\<sarang>** kayront: ?
+**\<kayront>** in fact, if you ask me, it opens up a whole new ocean of possibilities
+**\<kayront>** i mean the "guilty until proven innocent" spin on things
+**\<suraeNoether>** kayront there is a strong argumetn from the 1st and 4th amendment right that these financial transactions are free speech and demanding financial histories doesn't jive with the 4th amendment
+**\<sarang>** That's much broader than financial regulation
+**\<suraeNoether>** anyway
+**\<suraeNoether>** not totally relevant
+**\<sarang>** ya
+**\<suraeNoether>** it's interesting
+**\<sarang>** So... good meeting, I take it?
+**\<oneiric\_>** what does MRL think about using hashcash or a reduced monero PoW (like pool mining shares) to secure anonymity networks for p2p?
+**\<suraeNoether>** and political science-y, so we can call it research :D
+**\<sarang>** And you had said that the documents will be published?
+**\<kayront>** :D
+**\<sarang>** oneiric\_: what does that mean exactly?
+**\<suraeNoether>** yeah, sarang, i walked away feeling like it was a room full of allies both for financial privacy in general and for the twin monero-zcash ecosystems. i wasn't expecting that at all, tbqh
+**\<sarang>** nice
+**\<suraeNoether>** sarang: yes, all the reports will be made public on coincenter.org soon
+**\<suraeNoether>** oneiric\_: if you elaborate i could form an opinion :D
+**\<sarang>** In the meantime, anything else to share suraeNoether of interest?
+**\<lurkinandlearnin>** Sounds really interesting. I'll look into those reports when they drop
+**\<suraeNoether>** oneiric\_: i know that stellar uses a weird concensus mechanism involving picking neighbors to form a quorum vote, but rather than being a networking tool, it's intended to replace POW/POS
+**\<lurkinandlearnin>** Hadn't even heard of coincenter until now
+**\<suraeNoether>** sarang: I read the recent andrew miller paper on probing network topology blindly in bitcoin
+**\<oneiric\_>** so, anonymity networks (and ipv6) make it much easier for attackers to perform sybil attacks by spinning up many addresses (nodes) for little cost. adding some form of PoW would help mitigate that possibility by adding some effort to spinning up a node
+**\<sarang>** Interesting, I'd be interested to see how that would work
+**\<sarang>** and how a PoW integrates to it
+**\<suraeNoether>** sarang which is SUPER clever and it could be used similarly for boostrapping blockchain downloads or kovri networking or something like that, if a similar sort of feature can be exploited as in that paper
+**\<sarang>** suraeNoether: link?
+**\<sarang>** Not sure I saw that paper
+**\<suraeNoether>** https://www.cs.umd.edu/projects/coinscope/coinscope.pdf
+**\<sarang>** How new is it? Didn't see on IACR
+**\<suraeNoether>** i saw it tweeted end of last week iirc
+**\<sarang>** word
+**\<suraeNoether>** it's clever: it uses inputs with no known outputs and a bitcoin node's behavior when it receives such an input
+**\<suraeNoether>** it can't be relayed because it doesn't appear valid
+**\<sarang>** Huh, I shall read it today, thanks
+**\<suraeNoether>** yeha, they use a purposeful double spend attempt to suss out which nodes you are \*really\* connected to
+**\<suraeNoether>** anyway: that paper, plus sarang and my matching paper, comprise most of my time last week and this week other htan the workshop
+**\<suraeNoether>** (surae is done now)\\
+**\<sarang>** The matching paper is under its reasonably final review
+**\<sarang>** we'll post here for internal review soon, and then off to the presses
+**\<suraeNoether>** although at the end of the meeting i have a small community announcement
+**\<suraeNoether>** sarang we should also consider whether we want to publish our matching paper \*specifically in a journal\* or leave it as an MRL bulletin
+**\<sarang>** I also spent a good deal of time on that, but kudos to surae for a lot of work on it
+**\<sarang>** Right
+**\<suraeNoether>** i feel like it would be valuable to publish in an applied graph theory journal
+**\<lurkinandlearnin>** Sorry to interupt but could you explain what exactly "matching" means in this context?
+**\<sarang>** And it opens up to additional matching/weighting work too
+**\<suraeNoether>** lurkinandlearnin: ah, good question
+**\<sarang>** lurkinandlearnin: you can apply graph theory to a transaction graph
+**\<sarang>** and this means questions of Monero analysis can be reframed to known graph theory problems
+**\<suraeNoether>** lurkinandlearnin: the idea is basically to link transactions in a transaction graph. if it's just a plain old graph with no additional information, mathematicians call it a "matching problem" or an "assignment problem" or sometimes a "marriage problem"
+**\<sarang>** suraeNoether formalizes this
+**\<sarang>** soon (tm)
+**\<suraeNoether>** lurkinandlearnin: so we are applying known techniques to our graph, to get an overall sense of "how bad" our linkability really is, disregarding less complete approaches previous researchers have used
+**\<sarang>** Once again, a "please stop publishing on this" to others =p
+**\<lurkinandlearnin>** I see. So it's to abstract the data we can get from the blockchain to a form where these established techniques and theories can be applied?
+**\<sarang>** Right, we don't have to reinvent the graph-theoretic wheel
+**\<sarang>** and it also provides bounds
+**\<suraeNoether>** yeah, the number one problem with ring signatures and monero going back years is small anon set sizes. fluffypony makes this an important part of almost every talk he gives, but people still regularly publish papers that re-invent the wheel over and over again. "look, if two signatures have the same ring, you can ... you can... oh boy! i'ma publish!"
+**\<suraeNoether>** the novelty of our approach is we are able to find a lower bound on some specific instances of the matching problem
+**\<sarang>** It's basically how other types of security proofs go... if you could break X, it'd mean you would have solved Famous Math Problem Y
+**\<suraeNoether>** previous approaches have been able to say "well, matching monero is \*no worse\* than sharp P. https://en.wikipedia.org/wiki/%E2%99%AFP
+**\<lurkinandlearnin>** Interesting. So is the paper "groundwork" towards using these techniques or have you already got findings?
+**\<suraeNoether>** but that's like saying "it's no worse than the worst possible problemt hat God himself couldn't solve"
+**\<suraeNoether>** lurkinandlearnin: we are sort of generalizing many previous techniques at once and showing how they fit under a common umbrella
+**\<sarang>** We have some algorithmic findings
+**\<sarang>** Again, it'll be posted here for internal review soon
+**\<suraeNoether>** yerp
+**\<suraeNoether>** it's a good paper
+**\<suraeNoether>** i like it a lot
+**\<suraeNoether>** it really highlights how linkable Monero will be until we get larger anon set authentications
+**\<sarang>** Aside from that, Badass Benedikt Bunz put out a new paper on batching in accumulators: https://eprint.iacr.org/2018/1188
+**\<sarang>** Unfortunately it applies most directly to RSA accumulators, which are a no-go for us
+**\<lurkinandlearnin>** Thanks for the explanations. I'll look forward to it.
+**\<sarang>** np
+**\<sarang>** I'm working a ZtM update regarding spend proofs, which I realized are useful but missing from the tech documentation
+**\<sarang>** as well as some arithmetic circuit research
+**\<sarang>** Otherwise, just trucking along with lit review and code
+**\<sarang>** A side note that several funding requests are open, including those that fund MRL and other developers: https://forum.getmonero.org/8/funding-required
+**\<sarang>** In a bear market, pockets tend to shrink unfortunately :(
+**\<sarang>** (disclaimer: one of those requests is for me)
+**\<lurkinandlearnin>** Ain't that the truth
+**\<sarang>** Loki Foundation is still willing to help fund one of us
+**\<sarang>** to the tune of 15K USD total
+**\<sarang>** If the funding requests don't complete, I would consider accepting the fiat donation under the right conditions
+**\<kayront>** the bear spares no one
+**\<lurkinandlearnin>** Loki Foundation?
+**\<sarang>** Foundation associated to this group: https://loki.network/
+**\<sarang>** Monero-based, so they wish to support researchers (and no doubt it's good PR too)
+**\<sarang>** The Foundation as a legal entity is not allowed to donate in cryptoassets
+**\<sarang>** so they'd have to donate directly in fiat
+**\<lurkinandlearnin>** haha I searched before you answered and only found a german record label
+**\<sarang>** Anyway, I welcome comments on such an arrangement
+**\<sarang>** I would insist that there be no additional strings that wouldn't apply to any other FFS donor
+**\<sarang>** to ensure research independence
+**\<lurkinandlearnin>** Well I've never heard of them but if it can be guaranteed no strings then I don't see the problem
+**\<sarang>** My goal would be to ensure that it doesn't change the nature of MRL's support
+**\<sarang>** It wouldn't become MRL Brought To You By Loki Foundation
+**\<sarang>** Anyway, it could be a moo point if the FFS are funded; then Loki would be interested in supporting a new researcher if one came around
+**\<sarang>** Anyone else have interesting work to share with the group?
+**\<ilyaAldanov>** I do!
+**\<sarang>** carry on
+**\<ilyaAldanov>** But I guess the important stuff should go first.
+**\<ilyaAldanov>** I can go on after the meeting.
+**\<sarang>** Nonsense, all researchers are welcome here
+**\<sarang>** I'm finished with my update, please go ahead
+**\<sarang>** This is the point of the meeting
+**\<ilyaAldanov>** Today I want to present the return addresses.
+**\<ilyaAldanov>** Return address is a GREAT idea.
+**\<ilyaAldanov>** It's also MY idea, but that is unrelated.
+**\<ilyaAldanov>** It's quite simple: include sender's subaddress to every transaction header.
+**\<ilyaAldanov>** To make transactions unlinkable generate the subaddress from transaction's public key and sender's private key.
+**\<ilyaAldanov>** This way it's trivial to generate corresponding private key even after wallet restore.
+**\<sarang>** I was thinking about this earlier in the context of other timelock schemes
+**\<ilyaAldanov>** What good a return addresses for?
+**\<ilyaAldanov>** Many things!
+**\<ilyaAldanov>** The most obvious one: a full or partial refund (interactive).
+**\<ilyaAldanov>** A merchant can send you funds back without asking for your address.
+**\<kayront>** i'm sodl
+**\<ilyaAldanov>** Another one: an exchange can return funds that it can't bind to any account.
+**\<ilyaAldanov>** the famous PaymentID problem.
+**\<ilyaAldanov>** Or if the account is closed for some reason.
+**\<ilyaAldanov>** There can be non-interactive services.
+**\<ArticMine>** or AML / KYC
+**\<ilyaAldanov>** Like micro-credits.
+**\<kayront>** .. or returning unused FFS monies to their owners
+**\<ilyaAldanov>** You send a coin to the public address and get two in a month.
+**\<ilyaAldanov>** But even more!
+**\<kayront>** more, you say!
+**\<ilyaAldanov>** You send money to a specific address and receive a password to something in the dust.
+**\<sarang>** It'd be ~2% increase in a 2-2 txn size
+**\<ilyaAldanov>** Yes. But it's per-transaction, not per-output or per-input.
+**\<suraeNoether>** ilyaAldanov: it's a very interesting idea. if it works out, that means we have two possible ways of going about doing some sort of return functionality
+**\<ilyaAldanov>** It's the only 100% reliable link back to transaction owner.
+**\<lurkinandlearnin>** This is a 10/10 idea. The usefulness of these features could help push the more general adoption of subaddresses (which imo is a urgent goal).
+**\<sarang>** It'd be a fingerprinting method, as usual
+**\<ilyaAldanov>** Yes, but I want to stress out that my return addresses is not limited to refunds.
+**\<ilyaAldanov>** sarang ?
+**\<sarang>** Anytime some transactions include data that not all do, it distinguishes them
+**\<suraeNoether>** it'd be easy to discern who is using these return addresses and who isn't
+**\<ilyaAldanov>** Every transaction should have one.
+**\<ilyaAldanov>** No exceptions.
+**\<suraeNoether>** i can see why you would say that
+**\<suraeNoether>** or suggest it i mean
+**\<sarang>** Yes, but of course you can't make randomness enforced
+**\<lurkinandlearnin>** yes but you could see that the subaddress in the header has received funds in a future transaction, correct?
+**\<suraeNoether>** its essentially, what, 32 Bytes additional per transaction? not so bad at all given the functionality that would come out of it
+**\<sarang>** lurkinandlearnin: no, but you'd see an output in a ring
+**\<sarang>** 64 bytes
+**\<sarang>** 2% add-on to a 2-2 txn
+**\<suraeNoether>** rihgt
+**\<ilyaAldanov>** The return address is just a subaddress - nobody sees when it is used except the owner.
+**\<lurkinandlearnin>** yes sorry that's what I meant
+**\<suraeNoether>** i think we need a write-up before we can really judge how it's supposed to work, but it's v promising
+**\<sarang>** There is one
+**\<sarang>** not published tho
+**\<ilyaAldanov>** I don't publish it because a) it's a draft b) don't want the coins I don't like to implement it first.
+**\<sarang>** The construction of the subaddress is clever ilyaAldanov
+**\<sarang>** Heh, Monero doesn't need to be first, just best
+**\<suraeNoether>** sarang: there's a write-up for ilyaAldanov's idea?
+**\<sarang>** It was sent privately during discussions
+**\<kayront>** fwiw i find this a very interesting idea as well
+**\<sarang>** The more we discuss it, the more I like it
+**\<kayront>** opens up a lot of functionality
+**\<ilyaAldanov>** I sent it to Sarang and Isthmus. Can send to you as well.
+**\<suraeNoether>** seems less disruptive than DLSAG
+**\<kayront>** if it can be made to work without meta/data leakage, sounds like a no brainer
+**\<sarang>** Yes, but doesn't solve the same problems
+**\<oneiric\_>** +1 sounds like a great improvment over payment id
+**\<suraeNoether>** sarang: right, no timelock/block height stuff built in
+**\<sarang>** oneiric\_: it doesn't really solve payment ID either
+**\<sarang>** it acts as a band-aid for when they require payment ID and you forget it
+**\<sarang>** also it's interactive
+**\<sarang>** I'm just saying this is orthogonal to DLSAG
+**\<suraeNoether>** would they be do-able together or would it be one or the other only?
+**\<kayront>** DLSAG = ?
+**\<sarang>** You could probably do a separate return subaddress per output address
+**\<sarang>** MRL-0008: https://ww.getmonero.org/resources/research-lab/
+**\<ilyaAldanov>** If you ask me, I came up with many more use cases for return addresses.
+**\<sarang>** I definitely see the usefulness
+**\<suraeNoether>** DLSAG = dual-output linkable spontaneous anonymous group signatures
+**\<sarang>** But it's our job to rip every idea apart
+**\<ilyaAldanov>** I want to talk about one exceptionally useful case tomorrow.
+**\<sarang>** Not today?
+**\<ilyaAldanov>** One feature per day!
+**\<suraeNoether>** i.e.: usual ringCT but with two output keys and a trigger block before which the recipient of the first can spend the first and after which the recipient of the second can spend the second.
+**\<ilyaAldanov>** There was Hybrid Mining and Emission Curve days already.
+**\<sarang>** ilyaAldanov: it would be necessary to post the construction here for review
+**\<sarang>** this would need to be public, of course
+**\<ilyaAldanov>** Yes, of course.
+**\<sarang>** After you'd brought it up earlier, I started considering the effects this would have if it were optional (or effectively optional), especially on fake selections
+**\<ilyaAldanov>** But right now it's a draft. I really appreciate some comments, especially negative.
+**\<sarang>** This is an important consideration
+**\<sarang>** Even if it's mandatory, you should assume that wallets not using the functionality would be stupid and include all zeros or something
+**\<ilyaAldanov>** It'd be useless if optional.
+**\<lurkinandlearnin>** I like the fact that subaddresses have found another potential use.
+**\<sarang>** and determine what an adversary would do if it saw ring inputs from txns that include a "fake" return address vs a "true" one
+**\<sarang>** ilyaAldanov: I know, but you can't make randomness a consensus issue
+**\<ilyaAldanov>** That's a perspective I didn't think about. Thanks.
+**\<sarang>** It came up with payment IDs a while ago
+**\<suraeNoether>** ilyaAldanov: think about it this way: someone publishes a txn with the return key 000000000000001
+**\<suraeNoether>** how can you tell that's not genuinely random?
+**\<suraeNoether>** should it be blacklisted and not propagated?
+**\<suraeNoether>** what about 000..0?
+**\<ilyaAldanov>** Yep, I get the idea.
+**\<suraeNoether>** or what about 10101110010100111?
+**\<suraeNoether>** coolio
+**\<sarang>** The goal would be to ensure that even if wallets do this, it doesn't affect other users' rings
+**\<ilyaAldanov>** But there're many places where wallets can misbehave.
+**\<sarang>** Yes
+**\<ilyaAldanov>** Like in the change output.
+**\<sarang>** So we should assume they'll be awful and minimize the damage
+**\<sarang>** ilyaAldanov: if you approve, I can send your document to suraeNoether
+**\<ilyaAldanov>** I approve.
+**\<suraeNoether>** or just email it to me at surae@getmonero.org
+**\<ilyaAldanov>** But I want feedback!
+**\<sarang>** Sure; you'll get the best feedback if/when you release the draft publicly, tho
+**\<ilyaAldanov>** Are there any spies of the coins I don't like here?
+**\<suraeNoether>** ilyaAldanov: probably, but they also are not very good at their jobs :D
+**\<sarang>** probably
+**\<ilyaAldanov>** I don't like coins with premines, developer's rewards and obnoxious leaders.
+**\<sarang>** Welcome to Club Monero
+**\<sarang>** I assume Monono will steal this, but I'm ok with that
+**\<sarang>** So our time is nearly up... anyone else have info to share?
+**\<nioc>** a while ago there was a request for a recommended ring size for the next hard fork which is April and the code freeze is Jan. I know research has been done to address this request. Where do we stand in regards to a possible ring size increase?
+**\<sarang>** suraeNoether: you'd indicated you had a community announcement
+**\<lurkinandlearnin>** I am a spy
+**\<ilyaAldanov>** I'll publish it, just to put one more section about Shared Secret.
+**\<sarang>** cool
+**\<lurkinandlearnin>** oh wait I wasn't meant to say that out loud
+**\<sarang>** I do not see a reason to increase at this time
+**\<nioc>** but more is better :D
+**\<suraeNoether>** nioc: recent research suggests that increasing ring size \*may not\* be super helpful, even though \*the min time required\* to generate a guess at the true Monero transaction history is proportional to r: double r and you double that min time required
+**\<suraeNoether>** which sounds great
+**\<suraeNoether>** but it's not very efficient
+**\<suraeNoether>** i would rather: increase r by 1 and the difficulty doubles
+**\<sarang>** suraeNoether: your community annoucement? (I don't want to go over if people need to leave)
+**\<sarang>** Hmm he has vanished
+**\<lurkinandlearnin>** Community announcement: https://www.youtube.com/watch?v=CiRu\_W9tzM8
diff --git a/_posts/2018-12-31-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-31.md b/_posts/2018-12-31-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-31.md
new file mode 100644
index 0000000000000000000000000000000000000000..cf981d0896f1305e0c865d24f20cc1c5be82956a
--- /dev/null
+++ b/_posts/2018-12-31-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-31.md
@@ -0,0 +1,271 @@
+---
+layout: post
+title: Logs for the Monero Research Lab Meeting Held on 2018-12-31
+summary: Sarang work, Surae work, and miscellaneous
+tags: [community, crypto, research]
+author: el00ruobuob / surae
+---
+
+# Logs
+
+**\<sarang>** OK, probably low attendance today, but might as well see what folks are up to
+**\<sarang>** Hullo ll
+**\<sarang>** \*all
+**\<suraeNoether>** morning guys
+**\<sarang>** taptap this thing on?
+**\<endogenic>** good morning
+**\<suraeNoether>** howdy :D
+**\<dsc\_>** morn'
+**\<suraeNoether>** i'm actually excited for this meeting because its' been like two weeks
+**\<suraeNoether>** but i don't have much of an update, except "the matching paper is much \*shorter\* now"
+**\<suraeNoether>** :P
+**\<suraeNoether>** allrighty, so let's begin
+**\<sarang>** Heh, no problem
+**\<sarang>** I figure most people took it low this week anyway
+**\<sarang>** as tends to happen
+**\<suraeNoether>** as usual, we'll 1) open up with questions, 2) sarang and i will give some updates, and 3) we'll see if anyone else has been doing anything interesting
+**\<suraeNoether>** so, before we get fired up
+**\<suraeNoether>** who has some questions
+**\<suraeNoether>** ?
+**\<suraeNoether>** oh and, just before I forget: i want to bring the community up to speed on current thinking re: block size blowup
+**\<suraeNoether>** seems like no one has any burning questions
+**\<suraeNoether>** so, sarang, how about you jump in and give us a briefing on your holiday comings-and-goings
+**\<dsc\_>** Oh I have a question; what's the status on getting rid of / dealing with payment id
+**\<dsc\_>** (or integrated addresses, whatever the recent discussino was about)
+**\<endogenic>** dsc\_: i think we need to bring it up at a dev meeting
+**\<dsc\_>** ok cool
+**\<endogenic>** but i dont know
+**\<sarang>** There's general support for deprecation over time, but the question of how/when is still under active discussion
+**\<suraeNoether>** dsc\_: sgp\_ recently posted a draft blag post on the matter
+**\<sarang>** Right, but that should not be taken as any kind of consensus
+**\<suraeNoether>** i'm not sure how much further the discussion has gotten than the pastebin: https://www.irccloud.com/pastebin/cRwyJViz/monero%20scheduled%20address%20upgrade%20timeline%20%5Bdraft%5D
+**\<sarang>** very little
+**\<suraeNoether>** rihgt
+**\<suraeNoether>** this is still quite fluid
+**\<endogenic>** dunno sgp\_'s pretty good at representing that stuff :)
+**\<sarang>** Heh, very true
+**\<dsc\_>** cheers
+**\<sgp\_>** hello all
+**\<endogenic>** eyyyy
+**\<sarang>** Hi sgp\_
+**\<sarang>** Want to talk at all about your post draft?
+**\<sgp\_>** Sure. I outlined my best summary of how Monero will handle payment IDs going forward and how we got to that decision
+**\<sgp\_>** Of course, we all still need to agree
+**\<sarang>** I have been muddling over your post proposal
+**\<suraeNoether>** i just started reading it this mroning and i'm going to reserve my comments for later today
+**\<sarang>** A good deal of discussion centered around info leakage during multi-destination txns
+**\<sarang>** since there's only one payment ID per txn (kind of a PITA honestly)
+**\<sarang>** and not one per output, which is much simpler IMO
+**\<sgp\_>** This assumes unencrypted (standalone) payment ID prohibition in April 2019 and encrypted payment ID prohibition (use subaddresses instead) in April 2020
+**\<sarang>** To what extent do we have exchanges represented in the discussion?
+**\<sarang>** I operate on the assumption that no exchange reps are in any channels
+**\<sgp\_>** The most we've heard from any exchanges is from LocalMonero that helped initiate this discussion earlier this year afaik
+**\<sarang>** While I don't think we should make decisions based on exchange wishes, they represent a good chunk of user interaction
+**\<dsc\_>** To what extend would Sarang like to involve exchanges? I mean, probably most of us know some folk who work at exchanges, should an effort be made to get in contact?
+**\<sarang>** My thought has been as follows
+**\<sarang>** Exchanges need to do infrastructure work if we change pIDs
+**\<sarang>** and have little incentive to move to safer alternatives (e.g. subaddresses) without being required t
+**\<sarang>** to
+**\<sarang>** Setting a firm timeline is important, as is providing sufficient time to change
+**\<sarang>** There's almost certainly too few developers doing such things at exchanges
+**\<sgp\_>** I wrote up this post to help exchanges and other services be prepared, but we've had a historically difficult time reaching these services
+**\<dsc\_>** nice sgp\_
+**\<sarang>** One option has been doing wallet defaults only, and not consensus
+**\<sarang>** this at least makes most transactions more uniform
+**\<endogenic>** just in my personal view i dont think we need to worry too much about third parties… they're going to have to adapt
+**\<suraeNoether>** maybe part of our discussion should be to hold a call with some folks at exchanges or something like that, but my thoughts on the matter are in alignment with sarang's: the exchange will make whatever \*mandatory\* changes the core team decides upon, and it's not like they are going to be able to say "well, what if you guys did \*this\* instead, it'd be easier on us and it would lead to a better public key
+**\<suraeNoether>** infrastructure" or something. that's not their "mission" so to speak
+**\<sarang>** "we've had a historically difficult time reaching these services" <--- calls may be tough
+**\<endogenic>** who's going to pay us to reach out to them though? :)
+**\<sarang>** FFS to the rescue
+**\<sarang>** heh
+**\<dsc\_>** I can forward stuff to Kraken if neccesary
+**\<endogenic>** bah
+**\<endogenic>** the exchanges should
+**\<suraeNoether>** if monero moved to pairings based crypto tomorrow and we modified our whole key structure, they would groan, roll their eyes, curse our names, and then make the changes without publicly complaining at all
+**\<endogenic>** yes
+**\<endogenic>** agreed
+**\<sgp\_>** I may be able to talk to Circle and Poloniex. I have someone's email
+**\<sarang>** Cool. Step 1: make a damn decision
+**\<suraeNoether>** well, let's do a cursory reach-out. let's see if kraken, circle, and polo are willing to provide some feedback, even if it's "please don't make any changes for the love of god"
+**\<sarang>** unless we want exchange input well in advance of decisions
+**\<suraeNoether>** in the meantime, we'll prioritize a decision on this over the next few days
+**\<hyc>** polo has historically been pretty open to communication
+**\<endogenic>** feedback wont do harm
+**\<sgp\_>** We can still approve or reject this recommendation. Give them a pre-release of the press release of sorts
+**\<sarang>** that seems fair and in line with our transparency
+**\<suraeNoether>** yeah
+**\<dsc\_>** Cool. thanks guys.
+**\<sarang>** thanks sgp\_ for taking the reins on the public-facing side of this
+**\<sarang>** let's all review and think about options over the next few days as suraeNoether mentions
+**\<sgp\_>** I've received feedback from a few people. I'll make the changes to the doc this afternoon, but the overall message is the same
+**\<sarang>** esp. relating to timelines, consensus v wallet default, and the consequences on information leakage
+**\<suraeNoether>** okay, since we are on specific topics, before we move on to get sarang's research update, we may as well talk about the blocksize blowup thing
+**\<sgp\_>** One thing I claimed we are not doing: enforcing payment IDs. Are we in agreement here?
+**\<suraeNoether>** yes
+**\<sarang>** We can't effectively enforce encrypted IDs
+**\<sgp\_>** Cool, thanks
+**\<sarang>** and wallets can always be dumb about it anyway
+**\<sarang>** but having the default wallet do the right thing will help a great deal
+**\<suraeNoether>** okay, so regarding this blowup/dynamic block size problem
+**\<suraeNoether>** first: solutions are easy and numerous, each with pros and cons, but most involve magic numbers of some sort
+**\<suraeNoether>** for those of us in the audience, a magic number is \*arbitrarily chosen in code\*
+**\<sarang>** and consensus, which places a firm deadline on changes
+**\<suraeNoether>** yes
+**\<suraeNoether>** and this is sufficiently urgent of a problem that we should come up with \*some solution\* asap
+**\<sarang>** the gist of the problem: it's easy to blow up the block size by spending money, and it stays there
+**\<suraeNoether>** it's cheap to keep block size big, too
+**\<sarang>** yes
+**\<sarang>** There was a clever proposal to start the penalty \_below\_ the median
+**\<sarang>** to bring size down by default
+**\<sarang>** others involve (at the very least) a high cap that still avoids the crazy blowup possibilities
+**\<suraeNoether>** Options include but are not limited to
+**\<suraeNoether>** 1) change sample size of median block size to something very large like a year. pro: easy, ensures that an attacker has to be executing an attack for at least half a year before expecting any success. con: adds inflexibility to monero block size.
+**\<suraeNoether>** (it makes sense to make this increase in window size to be somehow proportional to our change in fees, to ensure that it doesn't cost \*less\* to attack today than before bulletproofs)
+**\<suraeNoether>** 2) add a momentum term to block size so that bigger changes are harder to effect. pro: also easy, improved flexibility. con: unlike median, determining the strength of an attacker required to execute the attack over a sustained period is a trickier question.
+**\<suraeNoether>** 3) change block size penalty to begin sub-median. pro: incentive against the attack! great! con: weak incentive, and a determined attacker is already blowing cash on this attack
+**\<sarang>** We should also consider the two parts to this: (1) getting the block size big, (2) keeping it big
+**\<suraeNoether>** yeah, we could add a rapid decay back to "small"
+**\<suraeNoether>** that requires lots of funds to counteract
+**\<suraeNoether>** 4) change block size dynamic updating to an \*additive\* update instead of a \*multiplicative update.\* Example: if median block size for the past N blocks is greater than some threshold, then change block size as S = S + diff\_S instead of S = r\*S for some r. Keep the \*decreases\* in blockchain size multiplicative. Pros: leads to an exponential decay in block size back to zero in the absence of demand, and leads
+**\<suraeNoether>** to at best a linear increase in block size in the presence of demand. Con: Not intuitive?
+**\<suraeNoether>** 5) limit the maximum change in block size over some time period by some factor. example: do not allow block size to grow more than 2x in a year. pro: easy to intuit, provides a cap on growth but still allows growth, etc. 2x a year is very fast exponential growth generally but we would have time to notice a bloat drift attack and maybe come up with other solutions. con: 2x a year is still very fast exponential
+**\<suraeNoether>** growth.
+**\<suraeNoether>** in all cases, we have to end up picking some magic numbers that would need to be justified to the community. example: why 2x a year instead of 1.05x a year, or 3x a year?
+**\<spaced0ut>** isn't prevention a little more important than the cure? rapid decays back would solve one issue but wasn't it determined someone could grow the chain 30TB or something quickly?
+**\<suraeNoether>** last I spoke to fluffypony about this, he said something like option (1) is most easy to get consensus on because we can justify a change based on the decreased fees. the change is pretty intuitive. with an 80% reduction in fees we could have a 5x increase in median sample size
+**\<sarang>** This needs a robust long-term solution, but also a short-term solution
+**\<suraeNoether>** spaced0ut: i agree with that sentiment
+**\<endogenic>** suraeNoether: imo the community doesn't need things justified to them so much as you have to consider them justified from a model pov - community looks to you
+**\<endogenic>** cause they'll be able to investigate what you propose
+**\<suraeNoether>** endogenic: i disagree. look at bitcoin block size debate or our current ring size debate. everyone wants a justification of the magic numbers proposed.
+**\<sarang>** FWIW the funds required to execute such a bloat attack to TB size are O(100K) USD IIRC
+**\<endogenic>** suraeNoether: monero != bitcoin tho.. big differences
+**\<sarang>** magic number != overall strategy tho
+**\<endogenic>** wow r u me
+**\<moneromooo>** If you ask for community consensus, you'll get the noisy ones to get their way, and they'll typically be short term profit people who <backspace a bit>.
+**\<sarang>** I want developer consensus
+**\<endogenic>** ^
+**\<moneromooo>** Oh, then that's much better. If you include people like ArticMine in this.
+**\<sarang>** Everyone will/should agree that avoiding TB bloat is worth changing shit
+**\<moneromooo>** People Who We Know Have A Clue.
+**\<suraeNoether>** \*nod\* i agree with all the above, to be honest
+**\<sarang>** at the very least, getting a worst-case short-term fix (like a high cap) in place for spring is the necessary starting point
+**\<spaced0ut>** as long as the change clearly shows everything possible is being done to have to avoid setting a hard limit like BTC. not many will think negatively.
+**\<suraeNoether>** i think for the spring hard fork, we should try for (1) and (3) together. start penalty at 80% median, and increase median sample size window by 5x.
+**\<sarang>** spaced0ut: a hard limit while we actively determine a more robust solution isn't all bad
+**\<sarang>** but I see the point
+**\<suraeNoether>** but before we make that decision, i want to back-of-the-napkin the cost of the attack before and after the change
+**\<suraeNoether>** Isthmus has been helping with some of that
+**\<suraeNoether>** but we should also make a decision on this v soon, like end of week
+**\<sarang>** Isthmus has a technical note draft on it
+**\<suraeNoether>** the cost of changing block size dynamics a second time later this year is low; the cost of permanently bloated blockchain is much higher in my mind
+**\<sarang>** If we establish an idea, we can compare to his original analysis
+**\<sarang>** yes
+**\<sarang>** doing nothing is the worst option
+**\<suraeNoether>** sarang: yeah exctly.. when he's done sleeping and recovering from the past month of work. :P
+**\<sarang>** OK, for the sake of this discussion, let's work up a proposal for combining options 1 and 3 from suraeNoether's list above
+**\<sarang>** (not right now, but I mean as an initial proposal)
+**\<spaced0ut>** sarang, i agree. its probably the safest option for XMR's longevity really. that won't be fun to explain so that most people understand though
+**\<sarang>** that will make the attack slow and expensive, and bring block size back down after such an attack
+**\<suraeNoether>** yep. let's shoot for end of week for our proposal
+**\<sarang>** spaced0ut: it's easy if you say "the consequence of leaving it is TB blocks"
+**\<sarang>** people hate bloat already
+**\<spaced0ut>** yeah
+**\<sarang>** These options have little effect on the average user if done properly
+**\<suraeNoether>** we don't really have MIPs do we? :P
+**\<sarang>** nope
+**\<sarang>** Every Commit Is a MIP (tm)
+**\<suraeNoether>** that should be on a t-shirt with several cows coding on the back
+**\<suraeNoether>** paging rehrar[m] i'd buy several of those shirts
+**\<suraeNoether>** well, two
+**\<sarang>** So
+**\<sarang>** This week I've been doing lit review in between Festivus celebrations, and doing some documentation writeups
+**\<moneromooo>** The intent of the block size increase is to allow sustained spikes (to the extent it is not an oxymoron). A year's smoothing will prevent that from working.
+**\<sarang>** moneromooo: yes, but at the cost of our simple model failing to prevent sustained bloat
+**\<moneromooo>** That seems to be a false dichotomy.
+**\<sarang>** Should sustained spikes not also yield a corresponding cost?
+**\<suraeNoether>** moneromooo: ehhh it doesn't prevent it. it merely raises the bar for what is required to push block size up, so spikes have to be sustained longer for them to impact the base layer. but you are correct; any time we have a variable/dynamic capacity, this allows for bloat, but fixed capacity is inflexible
+**\<suraeNoether>** but to be perfectly honest, if we find ourselves in a situation where people are regularly waiting until the next block to stash a transaction because the current block is full...
+**\<moneromooo>** This is a negative question, so "sustained spikes should yield a corresponding cost".
+**\<suraeNoether>** then in this situation, we probably will have some lead time to correct our block size dynamics to prevent it from being a systemic load problem
+**\<moneromooo>** The point is, if ytou have to waiut for half a year for the thing to kick in, it's pointless for spikes.
+**\<suraeNoether>** moneromooo: well, we can try one of the other methods that are more immediately flexible, like a momentum term or whatever
+**\<suraeNoether>** or we could just make fees great again
+**\<hyc>** yes ^
+**\<sarang>** heh yes to which
+**\<suraeNoether>** on the other hand, we could just recognize the dynamic block size flexibility to be a long-term flexibility instead of somethign designed to handle short-term volume spikes
+**\<hyc>** fundamentally, the reason bloating the chain is cheap is because fees are cheap and XMR/fiat is cheap
+**\<suraeNoether>** hyc yes
+**\<spaced0ut>** Just throwing an incomplete idea out there. Has anyone thought about increasing fee's as block size increases then decreasing fees based on some median tx count?
+**\<suraeNoether>** spaced0ut: the idea of blocksize-dependent fees is one that is very interesting to me, but i haven't dived into the idea
+**\<suraeNoether>** but that allows for an attacker to bloat the blockchain and drive everyone else's fees up, ala the bitcoin bloat from ... whenever that was. 2017? sheeee
+**\<tnsepta>** i think that one was just lots of real transaction activity?
+**\<hyc>** yes, but the net effect is the same
+**\<hyc>** everyone else's fees go up, to get their txs mined
+**\<suraeNoether>** okay, we'll think about this a little harder this week and see what there is to see
+**\<suraeNoether>** brb
+**\<tnsepta>** which is what makes this problem hard, you have to increase the cost of bloat attack without also making transactions way too expensive
+**\<tnsepta>** two sides of the same coin
+**\<hyc>** I would say that's an impossibility
+**\<tnsepta>** of course it's impossible to do both at the same time, i mean it's hard to balance the two right
+**\<hyc>** you can't distinguish "real" txs from "bloat" txs
+**\<spaced0ut>** the truth has been said in here multiple times already. it just sucks to admit. unfortunately our chain isn't insanely expensive to attack right now. there has to be a limit. make it complex or simple but it comes down to size not cost. can't make cost high enough without making it expensive for legit use.
+**\<hyc>** standard tragedy of commons scenario
+**\<sarang>** and size is dependent only on usage, of course... if you need to get N txns on chain, it costs O(N) in size no matter what
+**\<sarang>** Aight, that's two items of priority: (1) fee structure; (2) payment ID timeline
+**\<sarang>** Any other work of note?
+**\<moneromooo>** I'm doing some more work on multiuser txes (the type you can use, eg, coinjoin with).
+**\<moneromooo>** That might be interetsing to people here ?
+**\<sarang>** go on...
+**\<tnsepta>** is there a benefit of doing coinjoin when we're already doing RCT?
+**\<moneromooo>** Yes. Even more privacy.
+**\<moneromooo>** And atomic multi user spends.
+**\<tnsepta>** ahh ok
+**\<hyc>** does it require all participants to be online at once?
+**\<moneromooo>** There \*might\* also be a way to have smaller range proofs, but I'm not sure.
+**\<moneromooo>** No.
+**\<sarang>** Go on...
+**\<moneromooo>** Well, yes if you want it to be fast :D
+**\<hyc>** I always want computers to be fast.
+**\<sarang>** What's the basic structure moneromooo ?
+**\<moneromooo>** I'm making it like multisig. You pass a file around, and write your things. 2N-1 comms though.
+**\<sarang>** afaik this is the first I've heard of your work
+**\<moneromooo>** atm, I've got a first N comms rounds with everyone adding their inputs/outputs, then another ~N with people signing after checking their I/O are what they specified.
+**\<hyc>** who would want to use this approach?
+**\<moneromooo>** People who want to use a coinjoin style tx, and people who want to atomically pay.
+**\<hyc>** passing this file around sounds like it carries sensitive info, what's the danger of exposing it prematurely?
+**\<moneromooo>** (ie, Alice and Bob want to pay Carol, but only if the other also does)
+**\<moneromooo>** Not much I think.
+**\<sarang>** you're effectively doing partial signatures?
+**\<moneromooo>** You create MGs for the outputs you own.
+**\<moneromooo>** So kinda yes.
+**\<sarang>** MG?
+**\<moneromooo>** I think that's a MLSAG.
+**\<sarang>** The smaller range proof idea would be an MPC on a bulletproof?
+**\<sarang>** which is possible, but we've never had a definite use case
+**\<moneromooo>** I don't know. That'll be your job to find out :P
+**\<sarang>** heh
+**\<sarang>** well fwiw, bulletproof mpc is a known construction
+**\<gingeropolous>** damn, missed the bloat thing. i like 1 and 2. I think 1 can be the quick easy fix for now... and if we can figure out the best double mechanism (#2) then we should probably switch to that, because that can allow for spikes
+**\<moneromooo>** tnsepta: if you have more than one user, it breaks down some of the analysis you can do since you can't assume all inputs have a common owner.
+**\<sarang>** moneromooo: is there a branch with any work? or is it just at the "here's the math" stage?
+**\<moneromooo>** There's a "multi" branch, which has a PoC in core\_tests.
+**\<moneromooo>** I've started working on the simplewallet tooling now.
+**\<spaced0ut>** Could the same attack used to expand blocksize and bloat the chain also be used to create an insane amount of identical mixins to the point that future tx would have a high chance of having 10 identical mixins and your real spend?
+**\<sarang>** How do you get so much done simultaneously moneromooo ?
+**\<sarang>** Surely you burn the candle at all ends
+**\<moneromooo>** I have four legs. Humans only use two hands to type.
+**\<sarang>** spaced0ut: what do you mean?
+**\<sarang>** Do you mean the ring union analysis method?
+**\<sarang>** it's extremely unlikely to occur without active selection
+**\<sarang>** Unless you mean that the adversary controls a large percentage of available outputs and therefore knows other true spends?
+**\<spaced0ut>** okay. i wasn't sure if that held true in a scenario where the chain grew 100x larger and an attacker was sending the exact same amount every time. i'm a noob on input selection
+**\<sarang>** In that case, sure, that's always a possibility for an attacker who wants to spam the chain
+**\<sarang>** Amounts are irrelevant
+**\<spaced0ut>** yes ofc. i worded that funny. you answered me though thanks
+**\<sarang>** roger
+**\<sarang>** moneromooo: your idea intrigues me, and I'll be interested to examine the details
+**\<sarang>** Well, we have come to the end of our allotted time
+**\<sarang>** Great discussion all around
+**\<sarang>** We'll each move into the future sometime today; let us know what it's like when you get there
diff --git a/_posts/2019-01-07-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-07.md b/_posts/2019-01-07-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-07.md
new file mode 100644
index 0000000000000000000000000000000000000000..1b72cd492b83322b98d46e21b6e2b085bdc5e0c5
--- /dev/null
+++ b/_posts/2019-01-07-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-07.md
@@ -0,0 +1,269 @@
+---
+layout: post
+title: Logs for the Monero Research Lab Meeting Held on 2019-01-07
+summary: Sarang work, Surae work, and miscellaneous
+tags: [community, crypto, research]
+author: el00ruobuob / surae
+---
+
+# Logs
+
+**\<suraeNoether>** okay everyone
+**\<suraeNoether>** time for our Monday research meeting
+**\<suraeNoether>** before we get going, let's open up the meeting to questions! i like questions
+**\<moneromooo>** I want to know whether knaccc's propose change to the ecdh mask is good/safe, so I can code it early enough for the fork.
+**\<suraeNoether>** is knaccc around? i'm still unclear enough on the details of \*what exactly\* is being proposed. in terms of security, picking a mask from the same set as the value to be hidden is fine to do, but the devil is in the details
+**\<sarang>** Right, so the idea was to make the ECDH amount mask deterministic from the shared secret
+**\<suraeNoether>** i thought it was to select the mask from a smaller set so we can describe it with fewer bytes
+**\<sarang>** e.g. mask = H('mask',z,i) for example
+**\<sarang>** There was a separate idea to shrink the size of the encrypted amount data type
+**\<sarang>** making the mask deterministic means you shave 32 bytes off each output
+**\<suraeNoether>** ah, i see. and the question is "will this be good enough entropy because z itself is hashed?"
+**\<sarang>** The only thing to consider, I think, is that outputs with the same index and shared secret share a mask
+**\<suraeNoether>** if we are concerned with loss of entropy, we can use HMACs. they don't lose entropy after iteratively hashing in the same way... oh
+**\<suraeNoether>** what if we add an additional nonce that indicates the index among the outputs, assuming the output keys are lexicographically ordered?
+**\<sarang>** From an MLSAG perspective, we care only that the mask is uniformly distributed and known only to the sender/recipient
+**\<sarang>** that's what the proposal includes
+**\<suraeNoether>** ie H(m,z,i,j) where j = j^th output
+**\<suraeNoether>** oh
+**\<suraeNoether>** i'm clearly catching up on this. :P i didn't know this was written up, can I get a link?
+**\<sarang>** I don't believe that was written up AFAIK
+**\<suraeNoether>** oh, then i feel a little less bad
+**\<suraeNoether>** wait quick question
+**\<suraeNoether>** H('mask',z,i,j)... z is the amount being masked here?
+**\<sarang>** No, z is the shared secret; z=arG in the standard address case
+**\<sarang>** The encrypted amount is still included elsewhere in the ecdh data
+**\<suraeNoether>** yeah, looks fine to me. my only concern is that an adversary gets some partial control over z
+**\<sarang>** How?
+**\<suraeNoether>** but that's taken care of by CDH
+**\<suraeNoether>** sender picks r
+**\<suraeNoether>** recipient picks a
+**\<suraeNoether>** they both have a little control
+**\<sarang>** Well previously we used a random mask and used z to encrypt that
+**\<sarang>** So anyone who got z could compute the mask anyway
+**\<sarang>** The difference here is that the mask is now completely deterministic
+**\<oneiric\_>** is there a "known-best" algorithm, or set of algorithms, for generating a bounded random distribution?
+**\<suraeNoether>** oneiric\_: you mean a uniform distribution on a bouned set or...?
+**\<suraeNoether>** that's true, sarang, but ...
+**\<sarang>** ...
+**\<suraeNoether>** there's a difference here, and i need to figure out how to express it. one moment.
+**\<sarang>** The way I see it, the difference is only that the mask is now deterministic but still limited to the view of sender/recipient
+**\<sarang>** It's reused if the same shared secret is used elsewhere with identical index
+**\<oneiric\_>** suraeNoether: mean like, obfs4 generates random padding for dpi resistance. they bin based on common tor packet sizes. would like to know if there are particular mutations should perform on sampled, binned sizes to get a good random distribution
+**\<suraeNoether>** okay, so the difference here is that \*partial adversarial control over this z\* is being combined with using z as input for a one-way function that is allegedly masking some secret information.
+**\<suraeNoether>** the sender presumably wants to protect their own amount
+**\<suraeNoether>** the recipient could just reveal their own private view key if they want to be a jerk
+**\<suraeNoether>** so control over view key a isn't a big deal
+**\<sarang>** Our use of hash functions is about as uniform as you can expect (slight bias with H\_s)
+**\<sarang>** Again, keep in mind that anyone who can compute the shared secret (e.g. view key) can \_already\_ decrypt the mask now
+**\<suraeNoether>** right, the only fix i can think of would be computing H('mask', HMAC(z), i, j), which would sort of ensure that the security reduces to \*revealing z,\* following the strength of hmacs
+**\<sarang>** and thereby reconstruct the amount commitment
+**\<suraeNoether>** and i'm not sure what would be "fixed"
+**\<suraeNoether>** other than, in general, i like avoiding using any adversarially controlled data as input for protecting a secret
+**\<sarang>** Pro: shave off 32 bytes per output; commitments themselves are not deterministic
+**\<sarang>** whoops, that was for the con list
+**\<sarang>** Only downsides I see in practice relate to reuse of shared secrets
+**\<suraeNoether>** well, if it's two separate transction,, the sender should select two distinct random keys
+**\<sarang>** Sure, but they don't have to
+**\<suraeNoether>** but what if a sender maliciously selects the same random transaction keys on purpose? what happens? the mask is the same for two different transactions.
+**\<suraeNoether>** right
+**\<suraeNoether>** but the sender already knows the amounts
+**\<sarang>** In any case, it only leaks information that the two parties had already
+**\<knaccc>** if you use the same r or s with the same recipient twice, i don't think that's a security breach
+**\<knaccc>** it's a linkability breach though
+**\<sarang>** But it was already
+**\<knaccc>** yes
+**\<suraeNoether>** knaccc: if i'm an observer and i know two transactions use the same mask, i can figure out which transaction is larger and i can compute the \*difference in amounts\* between those two transactions
+**\<suraeNoether>** so i suppose this could be a way for a sender to surreptitiously leak transaction amounts to exterior parties without ever revealing anything to them directly
+**\<sarang>** suraeNoether: that was already possible
+**\<knaccc>** suraeNoether yes i agree
+**\<knaccc>** right yes, they could always set the same mask twice
+**\<knaccc>** now there is only one random variable to not screw up :)
+**\<suraeNoether>** on the other hand, the problem can be avoided by computing the mask as H('mask', z, i, P\_output) where P\_output is the output key being masked.
+**\<sarang>** Not even that... the encrypted amounts already use the shared secret
+**\<suraeNoether>** why not H('mask', z, i, P)?
+**\<knaccc>** sarang lol yes good point
+**\<sarang>** In fact, encrypted amounts should also use P
+**\<suraeNoether>** okay, so including P seems to be a good way to avoid the lex ordering above too
+**\<knaccc>** holw on, what's z? the shared secret?
+**\<suraeNoether>** heck, you could include as much crap in that hash as possible, like the signing ring and everything public
+**\<sarang>** Oh heh, including P really does nothing
+**\<suraeNoether>** knaccc: yeah, rA = aR
+**\<sarang>** it's determined from z entirely
+**\<sarang>** d'oh
+**\<suraeNoether>** oh hehe
+**\<sarang>** Reusing this to the same full address will gain you nothing
+**\<sarang>** So: the motto is basically not to reuse shared secrets, or you're already being bad to yourself
+**\<suraeNoether>** and you may be being bad to your recipients
+**\<knaccc>** suraeNoether do you really mean Hs(aR||i)?
+**\<suraeNoether>** knaccc: yes
+**\<suraeNoether>** i think
+**\<knaccc>** cool just checking
+**\<suraeNoether>** \*thumbs up\*
+**\<knaccc>** cos it's only the per-output shared secret that is ever used anywhere
+**\<suraeNoether>** okay, moneromooo sarang
+**\<suraeNoether>** oh wait
+**\<sarang>** ...
+**\<suraeNoether>** okay i agree, re-using transaction keys r is the root of all evil.
+**\<suraeNoether>** but we need some way to order these keys for multiple outputs at least
+**\<moneromooo>** So since money is the root of all evil... you make money by reusing transaction keys ?
+**\<knaccc>** suraeNoether the ||i in the per-output shared secret does that, right?
+**\<suraeNoether>** heh
+**\<sarang>** yes
+**\<suraeNoether>** yes
+**\<suraeNoether>** yeah, that's a good way to deterministically derive masks
+**\<suraeNoether>** i like it
+**\<suraeNoether>** okay, moving along: do we have any further questions?
+**\<sarang>** There was the question of a reduced amount ecdh size
+**\<moneromooo>** I'd like to get that written out with details ^\_^
+**\<oneiric\_>** just the one about random distributions...
+**\<moneromooo>** The final "this is good, safe and vetted" version if you will.
+**\<suraeNoether>** oneiric\_: i need a little bit more detail on your question
+**\<moneromooo>** I thought the amount size one was already vetted ?
+**\<knaccc>** very non-urgent, but there is the refund scheme. https://paste.fedoraproject.org/paste/lpM4dWKuV7KKCeAPn~P4Fw/raw
+**\<suraeNoether>** knaccc: yeah i started reading that right before the meeting
+**\<sarang>** Regarding the 64-bit amounts, I know it was discussed earlier but thought it best to bring up in meeting for a final thumbs-up
+**\<oneiric\_>** suraeNoether: what more information do you need?
+**\<suraeNoether>** oneiric\_: " they bin based on common tor packet sizes. would like to know if there are particular mutations should perform on sampled, binned sizes to get a good random distribution" <--- do you mean you have a histogram and you need to pick a random number from that histogram as if it were a probability distribuiton? i'm not sure what you mean yet.
+**\<oneiric\_>** picking from a histogram sounds pretty close to what i want to do, or close to what obfs4 does
+**\<suraeNoether>** sarang: let's collaborate on an ascii one-sheet for moneromooo on both amounts and masks for moneromooo
+**\<suraeNoether>** oneiric\_: oh then the answer is: hells yes
+**\<suraeNoether>** i'm not sure if this is sufficiently on-topic for the room
+**\<oneiric\_>** ok, will keep looking elsewhere. thanks suraeNoether
+**\<sarang>** Can we confirm people's thoughts on reducing ecdh amount size?
+**\<suraeNoether>** oneiric\_: nah, i got you in PM
+**\<sarang>** Right now encrypted\_amount = amount + H(z)
+**\<oneiric\_>** :)
+**\<sarang>** all are 32 bytes as usual
+**\<sarang>** the proposal was to reduce amount to 8 bytes, take the bottom 8 bytes of H(z) and XOR
+**\<sarang>** thereby keeping that data type down to 8 bytes
+**\<knaccc>** moo has reimplemented that as encrypted\_amount = keccak("amount" || shared secret)
+**\<knaccc>** mooo\*
+**\<sarang>** Sure, that's even better
+**\<sarang>** Er, wait
+**\<sarang>** that's the final encrypted amount sent to the recipient?
+**\<knaccc>** oops i left out tons. i meant encrypted\_amount = 8 byte amount XOR 8 bytes of keccak("amount" || shared secret)
+**\<sarang>** aha
+**\<sarang>** yes
+**\<sarang>** I seem to remember suraeNoether had much to say about this earlier when it was first brought up?
+**\<knaccc>** i think surae might have been thinking about what would happen if there was an auth tag or something to check brute force attempts against
+**\<suraeNoether>** nope, i never should have brought auth into the discussion becuase it was aside the main point
+**\<sarang>** Is output index also considered in this hash construction?
+**\<suraeNoether>** so the main thing my concern was
+**\<knaccc>** yes the entire thing is encrypted\_amount = 8 byte amount XOR 8 bytes of keccak("amount" || Hs(8aR||i))
+**\<suraeNoether>** hiding an N-bit number with an N-bit number, mod 2^N
+**\<suraeNoether>** why 8aR? aR is guaranteed to be on the curve if A and R are both on the curve...
+**\<sarang>** Recipient can't guarantee anything about R
+**\<knaccc>** yes, but instead of checking if R is in the subgroup of G, we just mul8 so no check is required
+**\<knaccc>** everywhere you see people talking about aR, they really mean 8aR
+**\<knaccc>** that's something people don't discover usually until they read the code
+**\<knaccc>** because it's always ommitted for brevity
+**\<suraeNoether>** oh fantastic, that's fine
+**\<suraeNoether>** i usually only think about it when computing hash-to-piont
+**\<suraeNoether>** point\*
+**\<suraeNoether>** that's bad of me
+**\<moneromooo>** When people tell me aR, I compute aR...
+**\<sarang>** Hence writing up details on this as requested
+**\<knaccc>** moneromooo well in the ecdh case, you were using a shared secret that was based on 8aR
+**\<suraeNoether>** so, short answer on whether it's safe to just use 8 bytes of keccak to mask an 8 byte number
+**\<suraeNoether>** is yeah, it should be fine
+**\<knaccc>** partaay!
+**\<suraeNoether>** although rather than only xor'ing the first 8 bytes
+**\<suraeNoether>** you could break keccak(stuff) into 8 byte blocks and xor all of them
+**\<knaccc>** lol
+**\<sarang>** ?
+**\<sarang>** there's nothing to be gained from that
+**\<moneromooo>** Can I take this as a vote of non confidence in keccak ? :P
+**\<suraeNoether>** 8 byte amount XOR first 8 bytes of keccak XOR next 8 bytes of keccak XOR ...
+**\<suraeNoether>** no, it's simply using all the entropy from the output of keccak
+**\<knaccc>** it's pretty standard practice when you have a csprng to just xor the stream against the plaintext
+**\<sarang>** yes
+**\<suraeNoether>** yeah, it is
+**\<knaccc>** and you don't need more than 64 bits of entropy to encrypt 64 bits
+**\<sarang>** moneromooo: sure, replace keccak with the identity function for simplicity
+**\<moneromooo>** There is a pointless keccak you mean ?
+**\<knaccc>** i don't know what sarang means either
+**\<suraeNoether>** i'm just mentioning it's an option. if the first 8 bytes are indistinguishable from uniform, then great, but reducing the output of keccak to the first 8 bytes does a lot to hurt 2nd pre-image resistance.
+**\<moneromooo>** Hmm. OK. There's a few places where that's done. Like the payment id stuff.
+**\<moneromooo>** I think some subaddress stuff too.
+**\<knaccc>** right, so the question is whether the first 8 bytes of keccak are indistinguishable from uniform, which I think it is
+**\<knaccc>** otherwise it'd be a terrible hash
+**\<sarang>** I was only joking :/
+**\<knaccc>** hehe
+**\<sarang>** Yes, a subset of the hash output is uniform
+**\<suraeNoether>** i need to think about exactly how much 2nd pre-image resistance is even important here, though
+**\<sarang>** Keep in mind that the recipient does a commitment reconstruction too
+**\<sarang>** So any mismatch between encrypted amounts (which the sender can always just make up) and the commitment will be detected
+**\<sarang>** We should always assume that the sender is lying about the amount
+**\<suraeNoether>** even if we find two R, R' such that keccak("amount" || Hs(8aR||i)) is identical, we send two transactions to whoever controls the view key a, and the encrypted amount has the same xor mask... but so what? even if you took those two encrypted amounts and xor'd them together, you would cancel the mask, but then you just have two xor'd amounts... i don't know.
+**\<suraeNoether>** anyway, we can avoid the problem of 2nd pre-image resistance by XOR'ing all the blocks
+**\<suraeNoether>** i'm just not convinced it's important here
+**\<knaccc>** i think keccak is immune
+**\<suraeNoether>** keccak is pre-image resistant. truncations of keccak are not necessarily. easy example, the \*first bit\* of keccak is \*not\* second pre-image resistant
+**\<moneromooo>** So something like this ? https://paste.debian.net/hidden/38907823/
+**\<moneromooo>** (not tested yet)
+**\<knaccc>** if the first bit was not 2ndpreimageresistant, then it would not be a decent hash
+**\<suraeNoether>** moneromooo: that looks to do what i think it should do, yeah... but that's assuming sarang and others agree with me
+**\<moneromooo>** Well, it can't hurt, even if it's pointless.
+**\<suraeNoether>** knaccc: technically it's pre-image resistant \*asymptotically.\* but in the concrete sense of security, i can break 2nd pre-image resistance for the first bit in an astonishingly short period of time
+**\<knaccc>** it only helps if the randomness in the hash is not evenly distributed
+**\<suraeNoether>** moneromooo: yeah, the cost is a few milliseconds when signing. \*shrug\*
+**\<knaccc>** suraeNoether maybe you'll have to spell out how you'd do that, but i don't think that's possible if the first bit is uniformly distributed
+**\<suraeNoether>** knaccc: okay check it out
+**\<suraeNoether>** pick a random number x
+**\<suraeNoether>** compute keccak(x)
+**\<suraeNoether>** select the first bit
+**\<suraeNoether>** i have a 50% chance that your bit matches the first bit of keccak(0), and a 50% chance it matches keccak(1), and a 50% chance it matches keccak(2), and so on
+**\<knaccc>** yes
+**\<suraeNoether>** finding a 2nd pre-image for your bit is as rapid as finding a heads up fair coin
+**\<sarang>** this seems... pedantic
+**\<knaccc>** maybe i need to re-read the definition of 2nd pre-image resistance and why it matters in this scenario
+**\<sarang>** for the level we're working with (2^64) it should not
+**\<suraeNoether>** it is. i'm just saying truncating a secure hash function according to whatever security property we are talking about... in general.... doesn't result in a secure hash function.
+**\<suraeNoether>** ^ it is \*pedantic\*
+**\<suraeNoether>** knaccc the answer you are looking for perhaps is this: i have to try, in expectation, as many pre-images as there are possible outputs, before finding a 2nd pre-image
+**\<suraeNoether>** so asymptotically with a security parameter that gives you the ridiculous 1-bit case, it's still technically a secure hash function, i guess
+**\<suraeNoether>** it's just not practically one
+**\<suraeNoether>** anyway
+**\<suraeNoether>** sarang: how about you tell us about your work for the past week or so, and then i'll give my update, and anyone else doing any other work can chime in
+**\<suraeNoether>** and we'll wrap it up
+**\<knaccc>** suraeNoether ah sorry i know what you mean by 2nd pre-image resistance now, for some reason i was confused on terms. so yes, there is certainly a 2nd pre-image resistance issue at 64 bits
+**\<knaccc>** but not in a way that actually matters
+**\<sarang>** This past week has basically been a sandstorm of proposals to consider and review
+**\<sarang>** Payment IDs
+**\<sarang>** Refund addresses
+**\<sarang>** Block size and penalty structure
+**\<sarang>** and so on
+**\<sarang>** as well as the release of the second episode of Breaking Monero
+**\<knaccc>** oh yes i loved one of your metaphors in that vid
+**\<suraeNoether>** knaccc: right, finding a 2nd pre-image at 64 bits itself takes a long time. it's not cryptographically long periods of time short of 80 bits... but i can't really think of what such a pre-image would gain an attacker, either, so like I said i'm not sure how much it's necessary
+**\<knaccc>** can't remember what it was now
+**\<sarang>** Was it burning the envelope as a heuristic?
+**\<knaccc>** it was eating the envelope and walking away
+**\<sarang>** heh
+**\<knaccc>** i lolled like crazy on that
+**\<sarang>** The current loose consensus seems to be that a two-median approach to block size cap is reasonable but not ideal
+**\<sarang>** as it will at least slow the bloat
+**\<sarang>** For payment IDs there is less consensus about the timeline
+**\<suraeNoether>** my work this past week included: 1) some coding simulations for the matching paper, 2) working on the monero konferenco website, which should be up and running before jan 15, which is when i'm going to put out a formal call for papers (although i've already heard back from a few folks). 3) refund proposal by charuto (I think it was charuto?) and 4) block size stuff. i was going to participate in breaking
+**\<suraeNoether>** monero this week but I got caught up on the block size stuff, unfortunately... it appears to me like the problem with the blocksize debate boils down to this: we don't necessarily know what we want from our own dynamic blocksize adjustment methods
+**\<suraeNoether>** we know some loose ideas about what we want, like adapting for rapid short-term growth that handles, for example, the holiday season, and we want block sizes to stay small unless it's needed
+**\<suraeNoether>** but the details of what behavior is considered malicious and which should be adapted for ... these aren't totally clear to me. so i've been thinking about those things, too.
+**\<suraeNoether>** oh, and 5) fees. i've been thinking about fee strucutre. but that ties in with 4).
+**\<suraeNoether>** i just have not had time to get into the payment ID discussion :(
+**\<knaccc>** timelines are really about politics more than tech
+**\<sarang>** yes
+**\<sarang>** and the timelines for applications and users of pIDs
+**\<suraeNoether>** sarang: since pay\_id isn't necessarily a security issue, but they are so freaking annoying, where do you stand on timeline for deprecation?
+**\<sarang>** Well, they can be a problem if not enforced
+**\<sarang>** Most complete option is full deprecation of unenc/enc, which I support doing all at once
+**\<sarang>** probably fall 2019
+**\<sarang>** at the very least, remove unenc and enforce enc (to the extent possible) with wallet default
+**\<suraeNoether>** okay, guys, i want to continue some of these discussions for sure, but let's call it for the official meeting time
+**\<suraeNoether>** sarang, thank you
+**\<sgp\_>** Should I re-write my post to say all payment IDs are disallowed in the Fall 2019 upgrade?
+**\<sarang>** sgp\_: you were interested in learning who uses unenc, right?
+**\<sarang>** To get a better sense of who needs to switch over and for what uses
+**\<moneromooo>** Shapeshift does.
+**\<knaccc>** thanks guys
+**\<oneiric\_>** thanks all for the meeting
diff --git a/_posts/2019-01-14-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-14.md b/_posts/2019-01-14-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-14.md
new file mode 100644
index 0000000000000000000000000000000000000000..1f4bc8db24ee3d2d776d30875059c0d808c44799
--- /dev/null
+++ b/_posts/2019-01-14-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-14.md
@@ -0,0 +1,358 @@
+---
+layout: post
+title: Logs for the Monero Research Lab Meeting Held on 2019-01-14
+summary: Upgrade items, Research, and miscellaneous
+tags: [community, crypto, research]
+author: el00ruobuob / sarang
+---
+
+# Logs
+
+**\<sarang>** But, let's begin
+**\<sarang>** The agenda, as linked above: http://paste.debian.net/hidden/4ae0abc9/
+**\<sarang>** 1. GREETINGS
+**\<sarang>** hello all
+**\<ArticMine>** hi
+**\<oneiric\_>** o/
+**\<sarang>** We have much to talk about today
+**\<sarang>** I'm going to move the Matrix item to 1.5. META
+**\<sgp\_>** hello!
+**\<suraeNoether>** howdy
+**\<sarang>** charuto asked if we could do a deeper Matrix integration of this room
+**\<suraeNoether>** what does it entail?
+**\<suraeNoether>** i'm neutral on bridges generally
+**\<sarang>** Right now AFAIK, the room is a portal in matrix, and the desire is for a plumbed room
+**\<sarang>** https://github.com/matrix-org/matrix-appservice-irc/wiki/Permissioning-in-Portal-vs-Plumbed-rooms
+**\<sarang>** This would have the side effect of allowing Matrix-side ops to exercise control over Matrix users in the room, but not on the freenode side
+**\<suraeNoether>** i'm not really grokking the benefit
+**\<sarang>** And be consistent with how other rooms (e.g. monero-community) are set up already on Matrix
+**\<sarang>** charuto: are you present?
+**\<charuto>** yeah, it would mostly not change anything IRC side, just here on this side, would allow for a more visible monero research lab matrix room and some matrix moderation options
+**\<sarang>** charuto is already matrix-side op for other monero rooms
+**\<sarang>** Provided we have another admin as well, I am not opposed to this
+**\<sarang>** However, I'll request loose consensus from the room now before enabling
+**\<serhack>** Hi everyone
+**\<charuto>** and yes, sarang is correct, it's mostly for matrix-side consistency, so matrix users can simply join #monero-research-lab:matrix.org
+**\<suraeNoether>** okay, so i'm not really following why this is fine
+**\<suraeNoether>** charuto, no offense intended, please, but
+**\<suraeNoether>** if someone comes to the matrix room and thinks you are in charge... \*shrug\*
+**\<suraeNoether>** i don't see a benefit to this
+**\<sarang>** I originally had similar concerns, but that's possible right now with the portal room
+**\<suraeNoether>** i see this as an opportunity for someone to act as a middle man to interact with me, and that makes me nervous
+**\<suraeNoether>** sarang: we can't stop someone from starting a portal room but we don't have to give them permission to plumb
+**\<suraeNoether>** i literally mean no offense, charuto, i am sure you are running the rooms responsibly but
+**\<suraeNoether>** i'm open to changing my view
+**\<suraeNoether>** if someone can explain the benefits other than consistency
+**\<charuto>** i understand your concern, suraeNoether , but the alternative would be people not even getting to the room
+**\<suraeNoether>** i thought there was already a room
+**\<suraeNoether>** that is a portal
+**\<suraeNoether>** so
+**\<sarang>** If this makes it easier to use on the matrix side, and introduces no new problems that don't potentially already exist, I am fine with it
+**\<suraeNoether>** how does that work then
+**\<charuto>** the portal room will remain, im trying to add a plumbed room
+**\<charuto>** cant remove portal rooms
+**\<suraeNoether>** then how is the alternative people not getting in?
+**\<suraeNoether>** maybe i'm confused about how matrix works
+**\<charuto>** some people dont know how portal rooms work and only join publicly listed matrix native rooms
+**\<charuto>** on other monero channels, portal rooms always have less matrix users than plumbed rooms
+**\<charuto>** it's the difference of joining #monero:matrix.org or joining #freenode\_#matrix.org
+**\<charuto>** typo, #freenode\_#monero:matrix.org
+**\<suraeNoether>** uhm
+**\<sarang>** Given that suraeNoether is an op in this room, we won't proceed at this time if he objects
+**\<suraeNoether>** so i guess my question is now reverting to a rude one: are people who can't figure out how to go to freenode.net and typing /join #monero-research-lab going to be helpful contributors in this room
+**\<sarang>** This issue will be tabled until after the meeting, so we can move on and respect attendees' time
+**\<suraeNoether>** k
+**\<sarang>** On to 2. UPGRADE ITEMS
+**\<sarang>** The block size algorithm has been discussed at length here and in -dev
+**\<hyc>** (I think that's a fair question surae)
+**\<sarang>** Loose consensus seems to be that the recommended approach, a dual median cap, is a reasonable stopgap that slows bloat, but it not a long-term solution
+**\<sarang>** ArticMine: given your deep involvement in this, can you comment?
+**\<sarang>** the proposal on the table is to cap the next block at min[ 1.4\*median(100), 50\*median(100000) ]
+**\<sarang>** (others are welcome to comment as well)
+**\<suraeNoether>** i'm happy to endorse this
+**\<suraeNoether>** Isthmus may have thoughts on simulations, but he's always super busy
+**\<sarang>** A lot of debate centered around this not being a long-term solution, and I agree
+**\<ArticMine>** Yes I can comment on this.
+**\<sarang>** What this does is stretch the time required by a lot
+**\<sarang>** ty ArticMine
+**\<ArticMine>** Fist both the original proposal that I made and smooth's latest proposal fail because they are using the entire block to scale the long term median
+**\<sarang>** smooth's proposal being... ?
+**\<ArticMine>** So either one has an exponential that scales based upon 50x my original proposal or the burst is lost
+**\<ArticMine>** smooth's proposal is above in this thread I will try to find it
+**\<ArticMine> \<smooth>** A=median of last 100 blocks
+**\<ArticMine> \<smooth>** B=median of last 100000 blocks (arbitary number, might be changed)
+**\<ArticMine> \<smooth>** maximum block size is min(max(A,300KB)\*1.4,max(B,15MB)\*1.2) (again both numbers could be changed)
+**\<ArticMine> \<smooth>** existing method is max(A,300KB)\*2
+**\<sarang>** Since code freeze is presumably drawing near, what is your endorsement ArticMine for what to include in the next fork (Boron)?
+**\<ArticMine>** Right now I am working on a solution that addresses both of the above issues
+**\<ArticMine>** Basically I does not use the whole block to scale the long term median
+**\<ArticMine>** but only that part of the block that would have been legal using the long term median
+**\<suraeNoether>** ArticMine: is there a serious flaw in using min[ 1.4\*median(100), 50\*median(100000) ] ?
+**\<sarang>** A benefit of the current approach is that it seems not too large of a fundamental change to include as a stopgap until more complex approaches can be studied more deeply
+**\<ArticMine>** the 50x factor is applied at the end
+**\<suraeNoether>** like... if we spend another week trying to come up with a better method, is that a good usage of time for the possible benefit of using a different method?
+**\<ArticMine>** Also we leave the current block scaling formual alone
+**\<ArticMine>** and instead restrict that effective median block weight to put a rolling cap on it using the long term median
+**\<suraeNoether>** ArticMine: maybe i'm not following you... what do you mean by using the entire block to scale the long term median?
+**\<suraeNoether>** and what do you mean "only that part of the block that would have been legal"?
+**\<ArticMine>** Let us say that the long term median only allows 400000 bytes for a block
+**\<ArticMine>** But the short term median allows for 500000 bytes
+**\<ArticMine>** The lock is legal under both proposals because of the 50x factor on the long term median
+**\<ArticMine>** Block
+**\<ArticMine>** Under both current proposals the whole 500000 bytes is used to scale the long term median
+**\<ArticMine>** What I am saying is that we only use 400000 bytes in that example
+**\<ArticMine>** This avoids the 50 factor in scaling the long term median that smooth was concerned about
+**\<suraeNoether>** okay, i'm still a little confused, but let me ask a follow-uyp
+**\<suraeNoether>** well its the same question i asked earlier: what is the problem with using min[ 1.4\*median(100), 50\*median(100000) ] ? I'm still not following.. :(
+**\<sarang>** You still get exponential growth over time
+**\<sarang>** it's just slowed way down
+**\<suraeNoether>** okay, i understand that part
+**\<ArticMine>** The problem is that we are incorporating the 50 facto in scaling the long term median
+**\<suraeNoether>** ArticMine: can you get us a write-up of your suggestions some time in the next few days?
+**\<suraeNoether>** something formal to look at? at least a formula or something
+**\<sarang>** We will need to make a decision ASAP on what to do
+**\<ArticMine>** That is the essence of smooth'ss concern
+**\<ArticMine>** Yes
+**\<sarang>** Right now, the only slow-growth proposal that at least has a formula and a simulated graph is the one suraeNoether mentioned above
+**\<sarang>** so I will consider that the current "best option" for now until/unless we get the same detail before freeze
+**\<sarang>** moneromooo: when should freeze be?
+**\<ArticMine>** When is freeze
+**\<sarang>** We'll move on and assume freeze is "as soon as possible, and perhaps sooner"
+**\<suraeNoether>** my concern is this: the only way to prevent a literal exponential blowup is to put in some sort of hard cap
+**\<ArticMine>** I has to be a rolling hard cap.
+**\<sarang>** In the interest of time, on to payment IDs
+**\<ArticMine>** Never a fixed hard cap
+**\<moneromooo>** Unknown. Pony wanted to have a first build end of january.
+**\<sarang>** sgp\_: you looked into usage of payment IDs by popular services
+**\<sarang>** ok ty moneromooo
+**\<sarang>** I advocate no changes to block cap that haven't been simulated
+**\<sgp\_>** yes sarang, and it's about a 50-50 split between unencrypted and encrypted
+**\<moneromooo>** If ArticMine need one more week to finish proving his idea, then I'm totally fine waiting for this.
+**\<ArticMine>** That will work very well for me
+**\<sarang>** Awesome, thanks ArticMine
+**\<sarang>** sgp\_ and others had proposed candidate timelines
+**\<sarang>** and received some feedback from wallets
+**\<sarang>** Can you explain your findings sgp\_ ?
+**\<sgp\_>** Sure. Here is where we are at right now:
+**\<sgp\_>** https://usercontent.irccloud-cdn.com/file/k06P021t/image.png
+**\<sgp\_>** Though after speaking with Justin from X Wallet, they seem interested in meeting the April timeline to remove the payment ID field when sending
+**\<sarang>** endogenic (who runs mymonero) expressed general concern about the rationale for removing encrypted IDs, particularly citing UX
+**\<sgp\_>** Cake Wallet says they will remove support once exchanges no longer use it
+**\<sarang>** Based on these timelines, there is no consensus change until fall 2019 (Carbon fork)
+**\<suraeNoether>** endogenic: can you elaborate on your concerns?
+**\<sarang>** endogenic said he'd be unlikely to be available for this meeting
+**\<selsta>** sgp\_: No soft depreciation in the GUI?
+**\<dEBRUYNE>** In my opinion, the most important goal should be to remove the long unencrypted payment IDs
+**\<sgp\_>** Let me explain the timeline a little bit more
+**\<dEBRUYNE>** They are detrimental to UX. Also, I am personally kind of ambivalent on integrated addresses versus subaddresses
+**\<sarang>** Those with -lounge history should look at those logs from earlier today to see his full remarks
+**\<sgp\_>** As sarang stated, no consensus changes until Oct 2019 (Carbon), when all payment IDs (encrypted and unencrypted) will be disallowed
+**\<dEBRUYNE>** Subaddresses are obviously better, but I am not sure how feasible it would be to get all exchanges and services to implement them
+**\<sgp\_>** In April 2019, the official GUI will no longer support sending transactions with unencrypted payment IDs, and the official CLI will force users to use annoying flags to send
+**\<suraeNoether>** hmmm, endogenic makes some interesting points about the memory requirements for subaddresses at exchanges
+**\<suraeNoether>** namely: a big exchange will have to have huge hash tables
+**\<selsta>** sgp\_: The GUI PR I did is similar to the CLI, requires enabling in settings. Why did you mark it as no support?
+**\<endogenic>** mooo points out it wont be crazy.. 8mb for a million entries?
+**\<endogenic>** (i'm half here, half not. busybusy)
+**\<sgp\_>** selsta: I thought the plan was to remove entirely. I can make it look like the CLI if that's what we want
+**\<moneromooo>** I looked, it's actually 32 bytes + 8 bytes, so 40 bytes payload. Plus the tree overhead.
+**\<dEBRUYNE>** Removing them entirely in the next version is going to lead to loads of user issues
+**\<sarang>** dEBRUYNE: them = what
+**\<dEBRUYNE>** The option to use long payment IDs
+**\<dEBRUYNE>** To add them to a transaction that is
+**\<selsta>** sgp\_: https://github.com/monero-project/monero-gui/pull/1866 Disabled by default, can be reenabled in the settings.
+**\<sgp\_>** Is this preferred? https://usercontent.irccloud-cdn.com/file/4g4NYw3q/image.png
+**\<selsta>** IMO yes.
+**\<sarang>** It at least provides consistency for our default products
+**\<sarang>** If we let encrypted pIDs stick around, there remain distinguishability problems between those txns and those w/ subaddresses and no pID
+**\<sarang>** these are mitigated somewhat by the use of a wallet-default encrypted value
+**\<moneromooo>** Those will get a 8 byte payment id (if only two outs).
+**\<sarang>** subaddress txns?
+**\<moneromooo>** Yes.
+**\<sarang>** with a default enc value
+**\<sarang>** excellent; I thought that wasn't the case
+**\<sarang>** Meaning the two choices there are: (1) ban all pIDs at Carbon fork; or (2) allow encrypted with a wallet default for \_only\_ 2-out txns at Carbon fork
+**\<sarang>** Are there other options that I'm missing here?
+**\<moneromooo>** "Carbon" is confusing.
+**\<sgp\_>** Carbon is Oct 2019
+**\<sarang>** fall fork; the element is carbon
+**\<moneromooo>** Wait. Carbon has 12 protons doesn't it ? Already there ?
+**\<sgp\_>** If exchanges and pools batch Monero transactions now with payment IDs, then they will need to change their behavior nevertheless
+**\<sgp\_>** actually wait, they can't do that. disregard
+**\<sarang>** If we are specifying a wallet default encrypted ID for subaddress transactions as well, I am less concerned about what happens if encrypted is permitted
+**\<moneromooo>** Ah, 14 protons \*and\* neutrons. Shame on me.
+**\<suraeNoether>** since we cant' enforce payids to be encrypted/can't verify that the payid has been encrypted, this new chart says to me "we aren't doing antyhing about this until october":
+**\<sarang>** What we're doing is encouraging exchanges to move off unencrypted
+**\<sarang>** and requiring it in October
+**\<suraeNoether>** \*nod\*
+**\<sgp\_>** I would much rather move totally to subaddresses to streamline this process. mandatory encrypted payment IDs seems really clunky to me
+**\<sarang>** Deciding on the fate of encrypted is important, so they know what to code
+**\<sarang>** it's not mandatory
+**\<suraeNoether>** no sarang, it looks like in october we are even deprecating the encrypted payids
+**\<sarang>** StupidWallet2.0 can always put 0
+**\<sgp\_>** even default seems clunky to me
+**\<sarang>** suraeNoether: according to sgp\_'s proposal yes, but we're discussing the consequences of what happens if encrypted is allowed to live
+**\<sgp\_>** no one should use payment IDs when sending funds to subaddresses
+**\<suraeNoether>** ah
+**\<sarang>** No, but they're important for distinguishability
+**\<moneromooo>** You can tell subaddress vs non subaddresses btw: additional tx pubkeys.
+**\<sgp\_>** For Carbon, I'd much rather remove all payment IDs to solve the distinguishability issue
+**\<moneromooo>** It's all a bit shitty isn't it.
+**\<sgp\_>** \*mitigate to the same extent
+**\<suraeNoether>** i agree with sgp. this makes me ask why we are even specifying the difference between encrypted vs. unencrypted, if the plan is to deprecate both by the october upgrade, and nothing about them is changing before october, and we can't enforce any shift away from unenc anyway
+**\<sarang>** Yes moneromooo but it doesn't give away info in the case of, say, exchange true inputs
+**\<suraeNoether>** moneromooo: lol
+**\<suraeNoether>** moneromooo: i knew a guy with a tattoo that said "life is a big shit sandwich and every day is another bite"
+**\<suraeNoether>** seems like a similar sentiment
+**\<sarang>** suraeNoether: ignoring the chart, the question at hand is what to do about encrypted: keep around, or get rid of it in fall 2019
+**\<sarang>** sgp\_ recommends nixing them in fall
+**\<sgp\_>** yes
+**\<sarang>** endogenic and dEBRUYNE suggest keeping them around
+**\<sarang>** If we keep encrypted around, the wallet needs to always include dummy values
+**\<dEBRUYNE>** Suggest might be a bit excessive
+**\<sarang>** ok
+**\<suraeNoether>** sarang: if we keep encrypted around we may as well not make any changes
+**\<dEBRUYNE>** I am just skeptical of the feasibility of forcing all exchanges to upgrade to subaddresses
+**\<suraeNoether>** because there's no way to enforce that they are encrypted
+**\<moneromooo>** I'll probably just start warning about them when used, like I did for 256 bit ones earlier.
+**\<suraeNoether>** dEBRUYNE: it's more feasible than asking everyone nicely to only encrypt their payids
+**\<sgp\_>** I think that given the timeline, we should be abitious and encourage them to update
+**\<sarang>** suraeNoether: no, but we are nixing long pIDs in fall
+**\<dEBRUYNE>** I suppose it could work if some workgroup started contacting exchanges soon
+**\<sgp\_>** This is ~9 months away
+**\<dEBRUYNE>** That provides them almost 10 months to implement stuff
+**\<sarang>** so the wallets will always encrypt whatever value the exchange tells them
+**\<sarang>** It is true that we cannot enforce legitimate encryption over random values etc
+**\<sarang>** So for the upcoming spring (Boron) upgrade, CLI/GUI \_will\_ permit sending with long pIDs with a flag and terrifying warnings of death
+**\<sarang>** And we will have public notice that long pIDs will be consensus-denied in fall 2019
+**\<sarang>** We \_should\_ produce a decision about encrypted at the same time, so services know what to expect and start developing for
+**\<sarang>** But I am not seeing any firm agreement about the latter
+**\<sgp\_>** I argue that we should write a post including the aggressive timeline. Luckily, if there is an implementation disaster, we can always walk back with nearly no effort
+**\<suraeNoether>** fact of the matter is, either we want people using subaddresses, or not, and we certainly dont' want to keep adding mroe and more address types. usual address + unenc payid, usual address + enc payid, integrated address, subaddresses... especially since subaddresses are (1) efficient for users and (2) cover all the use cases, and since (3) we can't enforce the difference between the first three, but we can
+**\<suraeNoether>** enforce subaddresses, the way forward to me is totally clear
+**\<sarang>** moneromooo: why
+**\<sarang>** because of daemon parsing?
+**\<moneromooo>** Because it's always coming back.
+**\<moneromooo>** Yes.
+**\<sarang>** Is it more than parsing for size?
+**\<moneromooo>** I don't understand that question.
+**\<dEBRUYNE>** It has to parse tx\_extra afaik
+**\<sarang>** We're already over time, and we still need to bring up another upgrade change: commitment amount/mask changes
+**\<sarang>** Commitment masks will be generated deterministically and not included separately in the ECDH data, saving a bit of space
+**\<sarang>** Amounts will be shrunk to 8 bytes and XORed with shared-secret-hash data
+**\<sarang>** This is probably... less controversial than the other changes :/
+**\<sarang>** Any questions/comments on it?
+**\<sarang>** This was proposed by knaccc and talked about earlier here and in -dev
+**\<sarang>** moneromooo has a branch for it
+**\<suraeNoether>** yeah, sarang and i have considered it and we agree that this still provides the perfect hiding property of pedersen commitments, and commitments to amounts are as binding as they were before our proposed change
+**\<suraeNoether>** it's a small space optimization. knaccc had the idea, right? or who came up with iut?
+**\<sarang>** knaccc
+**\<sarang>** it's simple and clever
+**\<oneiric\_>** clever in a good way?
+**\<sarang>** yes
+**\<oneiric\_>** cool
+**\<dEBRUYNE>** Just in general, do you feel it's the worth the (potential) risk? Imo the size savings are not that significant
+**\<sarang>** Yes
+**\<sarang>** It doesn't leak additional information that sender/receiver didn't already hold
+**\<knaccc>** it's 56 bytes per output, but that's significant on a pruned transaction
+**\<sarang>** OK, in the interest of time, very briefly on to 3. RESEARCH
+**\<sarang>** There are now a few options on the table for refund addresses
+**\<sarang>** knaccc proposed one that involves no consensus changes
+**\<sarang>** another uses a non-interactive DLSAG approach but requires substantial overhaul to the plumbing with many subtleties, but could allow for payment channels etc.
+**\<sarang>** and another was posted (link in the agenda)
+**\<sarang>** just stuff to chew on, likely not before the upgrade IMO
+**\<sarang>** since it requires a lot of wallet fun
+**\<sarang>** moneromooo has been working on coinjoin-style fundamentals
+**\<sarang>** I'll be writing up some bulletproofs mpc for that
+**\<moneromooo>** thank you ^\_^
+**\<sarang>** I posted a few papers of interest in the agenda
+**\<suraeNoether>** ( still on the previous topic, but just a quick comment dEBRUYNE: the savings aren't that significant, but afaict, the security is concretely very similar (if not identical). It's a no-loss decision, in my mind )
+**\<sarang>** Since we're over time, any very quick updates from others? Then we'll review action items
+**\<suraeNoether>** sarang, are your comments on the matching paper complete? was our conversation last week all your thoughts or am i waiting on more notes from you?
+**\<dEBRUYNE>** I am just warry of the change somehow being exploited later on
+**\<moneromooo>** One question about refund addresses: only one of those proposals helps with payment channels ?
+**\<sarang>** I am nearly complete, was derailed by an unrelated topic
+**\<dEBRUYNE>** Does it necessarily matter we're over time btw? I don't mind continuing :p
+**\<sarang>** for non-interactive use
+**\<suraeNoether>** i started a "linear techniques in applied cryptography" document to keep my notes on Ruffing's scheme, Schnorr signatures, Bulletproofs, and Bootle's polynomial commitments all in one neat and tidy place. i may tweak it over the next year in little ways with the long term goal of writing a book
+**\<sarang>** We don't have a concrete proposal for integrating knaccc's or Ilya's schemes into a payment channel system safely
+**\<suraeNoether>** moneromooo: DLSAG is good for payment channels... cryptonote++ or ilya's paper... i believe that is non-channel based refund addresses
+**\<sarang>** DLSAG ensures you can properly track spends
+**\<sarang>** hence the tomfuckery with key images and signature style
+**\<sarang>** So for the sake of sanity, here are the action items that are time-sensitive:
+**\<sarang>** (a) block size cap algorithm: we need a method that has been simulated in time for freeze
+**\<sarang>** (b) payment ID timeline: we need to know the fate of each address type to make a unified statement for services to use for planning
+**\<sarang>** (c) any objections to the ECDH data change are at the "speak now" phase
+**\<sarang>** Non-sensitive items:
+**\<sarang>** (d) we can talk after the meeting about the Matrix room integration
+**\<sarang>** (e) the MRL-0011 paper will be released to this group when I get my reviewing ass in gear again
+**\<sarang>** (f) refund address options should be investigated more thoroughly to decide what route(s) to take
+**\<sarang>** That's all I wanted to get through. We can open the floor now to continuation of anything and everything
+**\<sarang>** Sorry for being a hardass on time today; wanted to make sure we hit everything
+**\<suraeNoether>** in order to address (c), we should write up a formal technical note on (i) how amount commitments are currently computed, (ii) our proposal for the new computation and (iii) proofs of equal security in terms of hiding and binding properties\\
+**\<suraeNoether>** and i can work with knaccc on that this week
+**\<knaccc>** Not sure if MRL is the right place for this, bu re: the embedded Java-I2P router idea, I've almost finished it. Just need to test my scripts a bit more. Available here: https://github.com/knaccc/embedded-i2p-java-router-with-sam
+**\<sarang>** OK, have you seen the branch moneromooo has already?
+**\<sarang>** it's in code
+**\<moneromooo>** 5052
+**\<suraeNoether>** oh man
+**\<suraeNoether>** i'll check that out
+**\<suraeNoether>** thanks moneromooo
+**\<sarang>** I know moneromooo and knaccc and I have looked it over
+**\<suraeNoether>** yeah, and i recall writing up a proof of the idea and satisfying myself about it, but that was on paper
+**\<suraeNoether>** which branch?
+**\<sarang>** rctb
+**\<sarang>** https://github.com/moneromooo-monero/bitmonero/tree/rctb
+**\<oneiric\_>** knaccc: cool work on the java-i2p embedded router
+**\<zlatinb>** knaccc: let me know if you need any help with the java embedding
+**\<suraeNoether>** found it right after i asked :P thanks sarang
+**\<knaccc>** oneiric\_ zlatinb thanks, any comments or suggestions welcome
+**\<moneromooo>** Are you adding i2p/monero connectivity ?
+**\<oneiric\_>** do you know if there are any hardening flags available for jlink?
+**\<knaccc>** not sure what you mean by hardening
+**\<oneiric\_>** aslr pie stuff like that
+**\<knaccc>** i don't think those things apply to Java
+**\<oneiric\_>** no?
+**\<knaccc>** that's kinda the point of Java
+**\<knaccc>** buffer overflows etc are impossible
+**\<knaccc>** even if you're brain dead
+**\<oneiric\_>** hrm, the jvm is still in c tho no?
+**\<zlatinb>** C++
+**\<knaccc>** oh the jvm itself is hardened over 2.5 decades by Sun/Oracle, in theory
+**\<knaccc>** there are no user flags i'm aware of for hardening it further, but i'll check
+**\<zlatinb>** jlink doesn’t really “link†anything in the sense of C/C++ linking
+**\<knaccc>** correct
+**\<knaccc>** it's static linking of java stuff
+**\<oneiric\_>** so, in java dev, there is no sense of hardening outside of writing good code?
+**\<zlatinb>** not really
+**\<suraeNoether>** OH GUYS I HAD AN ANNOUNCEMENT
+**\<suraeNoether>** as some of you know, Sarang and I have started a non-profit together called MAGIC - Multidisciplinary Academic Grants in Cryptocurrencies
+**\<suraeNoether>** and we are opening up our scholarship program this month!
+**\<oneiric\_>** congrats!
+**\<suraeNoether>** we are giving out 5 $1000 USD scholarships for this fall, and we are giving out 2 $3000 USD research grants in the upcoming spring
+**\<dEBRUYNE>** moneromooo: I think that's the intention
+**\<knaccc>** congrats surae
+**\<suraeNoether>** so, by the end of this month, our application will be available on https://magicgrants.org for anyone registered at an accredited school in the US, South Africa, or the EU or EFTA nations or micronations within the EU or EU-eligible nations.
+**\<suraeNoether>** all this is made possible by a single anonymous donor so far
+**\<suraeNoether>** i know the market has screwed all of us essentially, but if anyone wants to give, there are donation links both through globee for crypto and stripe for fiat on that webpage
+**\<knaccc>** very cool suraeNoether!
+**\<suraeNoether>** thanks knaccc!
+**\<suraeNoether>** hopefully by 2022 we can start building primary schools all over the world libraries and computer labs
+**\<suraeNoether>** well, in the listed nations for now. :P
+**\<sarang>** Side update: suraeNoether is fine with the Matrix plumbed room, as am I. Unless there are objections now (this was mentioned earlier to other room ops, with no reply) we'll go ahead and allow it
+**\<suraeNoether>** ah yeah i removed my objection because i realized we can always undo the decision later. :P
+**\<suraeNoether>** and i don't think charuto is a personel risk, although having a second mod would be keen
+**\<sarang>** Block cap algo is in ArticMine's court for now, with the current proposed dual-median in the wings
+**\<sarang>** Payment ID timeline is still annoyingly up in the air
+**\<sarang>** If anything, we should figure that damn thing out
+**\<knaccc>** moneromooo just in case it's not clear, I don't know a thing about the C side of things, e.g. how to add libsam3 to the Monero C code in order to talk to the embedded i2p router via the SAM protocol. But I am able to figure out how to produce an embedded JVM/I2P binary that can be bundled with zero installation and zero dependencies
+**\<moneromooo>** OK.
+**\<suraeNoether>** do we have an issue on github yet re: replacing pay\_id with subaddresses?
+**\<suraeNoether>** it'd be helpful to have some coherent arguments laid out in all the different directions
+**\<suraeNoether>** also does anyone have thoughts on this: https://github.com/monero-project/research-lab/issues/46
+**\<sarang>** That was brought up on reddit earlier, presumably by the same person
+**\<moneromooo>** When I see a post that has "it's going to be brushed off", I want to brush it off just because it said that. OTOH, a game theoretic analysis of this would be very nice, if possible.
+**\<sarang>** Yeah, I said that person is free to do it or put it out there for someone else to do, either volunteer or for FFS donations
+**\<moneromooo>** s/possible/not made up of mostly unknowable factors/
+**\<sarang>** ArticMine has brought up his views on supply but AFAIK they are not really documented anywhere
+**\<sarang>** and they should be
diff --git a/_posts/2019-01-21-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-21.md b/_posts/2019-01-21-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-21.md
new file mode 100644
index 0000000000000000000000000000000000000000..09ec3c9e578b112aeb42510b473400f160669c3a
--- /dev/null
+++ b/_posts/2019-01-21-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-21.md
@@ -0,0 +1,211 @@
+---
+layout: post
+title: Logs for the Monero Research Lab Meeting Held on 2019-01-21
+summary: Ongoing work, New work, and miscellaneous
+tags: [community, crypto, research]
+author: el00ruobuob / surae
+---
+
+# Logs
+
+**\<sarang>** FYI meeting begins shortly
+**\<sarang>** Current agenda: https://github.com/monero-project/meta/issues/301
+**\<sarang>** Shall we begin?
+**\<suraeNoether>** sure
+**\<sarang>** Greetings, everyone
+**\<suraeNoether>** letsdothis.gif
+**\<oneiric\_>** o/
+**\<sarang>** I dislike mass pings, but given certain topics, a special ping to sgp\_ ArticMine moneromooo knaccc
+**\<sarang>** First, ONGOING WORK
+**\<ArticMine>** Hi
+**\<sarang>** Much discussion about payment ID deprecation has occurred
+**\<sarang>** sgp\_ is holding an open meeting to discuss this, on 25 January: https://github.com/monero-project/meta/issues/299
+**\<sarang>** THe current proposal intends to discuss is a deprecation of unencrypted pIDs at next upgrade, followed by a ban on all payment IDs in fall
+**\<sarang>** The main source of contention at this point seems to be whether keeping encrypted pIDs around, whether or not the wallet supports them by default, is necessary or desired
+**\<sarang>** Unless there's something important to talk about regarding this, and its relationship to the upcoming fork, we can table it until sgp\_'s meeting
+**\<suraeNoether>** i think it's wise to table the discussion until the meeting
+**\<sarang>** moneromooo has been working on wallet handling of payment IDs, as well as the use of default payment IDs for transaction indistinguishability
+**\<sarang>** ok!
+**\<sarang>** Next is block size scaling
+**\<sarang>** ArticMine recently posted a new proposal \\
+**\<sarang>** So the two on the table right now are the dual-median option (presented last time) and ArticMine's new one
+**\<ArticMine>** I can go over the details and answer questions
+**\<sarang>** ty ArticMine
+**\<sarang>** Here is the paste on this idea, linked earlier: http://paste.debian.net/hidden/50f142a6/
+**\<lurkinandlearnin>** To confirm, the old proposal is this? https://github.com/noncesense-research-lab/Blockchain\_big\_bang/blob/master/models/Isthmus\_Bx\_big\_bang\_model.ipynb
+**\<ArticMine>** The key part of my proposal is to separate the block weight into a long term portion LongTermBlockWeight and the balance
+**\<ArticMine>** LongTermBlockWeight - BlockWeight
+**\<sarang>** lurkinandlearnin: look at notebook line [3]
+**\<ArticMine>** LongTermBlockWeight does not include the burst potion that can go up to 50x
+**\<ArticMine>** So the LongTermMedianBlockWeight does not compound at 50x
+**\<suraeNoether>** fwiw for the folks in the audience: one of the reasons block size based on medians is a difficult question is the way medians behave...
+**\<suraeNoether>** most equations that have been proposed here introduce an effective time delay between how max block size is responding to previous block sizes... and it's a difference equation... and introducing time delay to difference equations can introduce very strange behavior like chaos. (example: https://advancesindifferenceequations.springeropen.com/articles/10.1186/s13662-015-0374-1 )
+**\<suraeNoether>** chaos is bad
+**\<suraeNoether>** so most of these proposals are most easily analyzed with simulations, which provide no guarantee that things won't go crazy. i've been looking into mean-based appraoches instead of median-based approaches; this introduces the possibility that outliers become disproportionately important, but it removes chaos from the equations, so we may be able to design a globally stable approach.
+**\<suraeNoether>** in addition to evaluating articmine's proposal
+**\<ArticMine>** This is the key difference with the prior proposal that compounds the LongTermMedianBlockWeight using the entire block
+**\<ArticMine>** the
+**\<sarang>** Including the simple two-median approach, right ArticMine ?
+**\<ArticMine>** Yes the simple two median approach fails
+**\<suraeNoether>** i'm still not clear on the properties we want out of max block size adjustments
+**\<ArticMine>** Since it either compounds the 50x burst (my initial version) or kills the burst over time (smooth's version)
+**\<sarang>** ArticMine: is that paste complete as written?
+**\<suraeNoether>** beyond "ability to go 50x over a slow day to accommodate a christmas day, and to not allow a big bang"
+**\<ArticMine>** Yes
+**\<sarang>** Isthmus and I plan to work this in to our existing simulations
+**\<sarang>** His is more complete, but I am doing one for my own education and as a separate check
+**\<sarang>** We shall need to make a decision by freeze time
+**\<sarang>** ArticMine: there are a few subtleties that I'll want to ask you about later
+**\<sarang>** But I also would like to hear the answer to suraeNoether's question
+**\<nioc>** I did not see any response to smooth's comment.....
+**\<nioc>** you can avoid any sort of consensus issues on \*1.4 by making it 1.375 which is adding 3/8
+**\<nioc>** 10:50 PM or some such, but that should be close enough
+**\<nioc>** 10:56 PM overall looks good to me at first reading
+**\<nioc>** 11:02 PM i guess 4/10 is fine too, just slower (but not significant)
+**\<sarang>** that was a rounding issue, I suppose
+**\<moneromooo>** If people will fuck up with 1.4, they will fuck up with 1.375.
+**\<moneromooo>** For interested people, the amp branch has ArticMine's change (untested).
+**\<suraeNoether>** we should just pick a number that can be represented exactly in a computer
+**\<moneromooo>** (just the top patch)
+**\<moneromooo>** Better to pick one that can't. You don't want people to use floating point and think they did it right bevause the number was chosen to make things look right.
+**\<sarang>** branch link: https://github.com/moneromooo-monero/bitmonero/commit/f1ee51c55963d05a78db916d41da7dc5948bb05a
+**\<suraeNoether>** representing 1.4 in a computer is inexact and will cause floating point rounding problems in different pieces of software, but i think 1.375 can be represented in binary exactly and so there is no roundoff problem in that regard...
+**\<sarang>** also, hot dang that was fast moneromooo
+**\<suraeNoether>** one of the things i, personally, would like out of the block size adjustment is this
+**\<ArticMine>** smooth's comment would e an improvement if the BlockWeight were a factor of 8 in bytes, but it is not. So in reality it is not a material change
+**\<suraeNoether>** moneromooo: that's a strong argument actually
+**\<suraeNoether>** so, i think block size adjustment can benefit from: forcing the marginal cost of adding an additional transaction in terms of block reward penalty to be greater than the standard fees gained by including that transaction
+**\<suraeNoether>** even if we pick some exotic max\_block\_size calculation, we should also be changing the block reward penalty this way
+**\<ArticMine>** Still I see as an improvement. As per suraeNoether comment above. So we can make the change from 1.4 to 1.375
+**\<suraeNoether>** of course, if the block is nearly full and the block reward is almost zero, adding almost any transaction fees will make up for it
+**\<suraeNoether>** ArticMine: moneromooo just made a strong argument \*against\* that
+**\<suraeNoether>** so this marginal cost approach will be most effective when block sizes are nowhere near the big bang levels
+**\<suraeNoether>** which is good: providing an incentive to stay reasonable when they are already reasonable
+**\<ArticMine>** No When block weight is close to big bang levels LongTermBlockWeight is << BlockWeight
+**\<suraeNoether>** i'm not talking about your block size proposal; i'm talking about block reward penalty as a function of block size
+**\<lurkinandlearnin>** Has any thought been given towards an incentive for miners to create smaller blocks when transaction volume is low? To slow blockchain growth
+**\<suraeNoether>** that's what i was just talking about lurkinandlearnin
+**\<pigeons>** lower blockchain growth is probably less important than quicker validation and propogation but the same point applies
+**\<sarang>** lurkinandlearnin: all txns get added eventually if the fee market allows
+**\<suraeNoether>** something isthmus brought up to me: there are only about 150,000 blocks between us and the next hard fork. with the \*simple\* two-median method will forbid a blowup before the next hard fork.
+**\<suraeNoether>** woops i mean between March and October hard forks
+**\<moneromooo>** Yes, starting the penalty before 100% (idea from smooth).
+**\<suraeNoether>** we should consider implementing the simple method \*first\* and spending time thinking about a more optimal solution, rather than trying to go for broke
+**\<lurkinandlearnin>** moneromooo: that sounds like a great idea
+**\<suraeNoether>** moneromooo: yep, smooth had the initial idea of sub-100%-median block penalty; my idea is to make the drop-off nonlinear so that it's more expensive to push block sizes larger in the absence of a healthy fee market
+**\<sarang>** Well, simulations will shortly be done for ArticMine's proposal compared to the current approach and the simple two-median
+**\<sarang>** Presumably the next upgrade will do one of the two options
+**\<suraeNoether>** okay, i don't think we're going to come to any conclusions on this, but it's been a good update
+**\<suraeNoether>** let's move past scaling
+**\<sarang>** Sure thing. We'll talk after simulation data are available
+**\<sarang>** Next is transaction size reduction, for which there is a PR from moneromooo
+**\<sarang>** AFAIK there are no new updates on this otherwise
+**\<sarang>** unless moneromooo you wish to say anything about it?
+**\<moneromooo>** I'd just like one of you Noethers to review the code before it goes in.
+**\<moneromooo>** suraeNoether said he'd have a look.
+**\<suraeNoether>** sarang let's do that \*together\* tomorrow morning? we can do it over a vidchat since we were going to meet tomorrow anyway
+**\<sarang>** Roger; the math looked correct to me, but I may have neglected to add a comment
+**\<sarang>** ok suraeNoether can do
+**\<suraeNoether>** fun
+**\<suraeNoether>** as for the semi-final point on the agenda... what's the deal with bulletproofs, anyway? seinfeld.gif
+**\<sarang>** lol
+**\<suraeNoether>** DID YOU GUYS MAKE THINGS FASTER AGAIN
+**\<sarang>** Only a brief update that some BP verifier optimizations didn't make it into the 0.13 release
+**\<sarang>** a very unscientific test on my box resulted in a 64-batch of 2-proofs verifying 60% faster
+**\<sarang>** kudos to moneromooo for continuing to squeeze speed out of those suckers
+**\<lurkinandlearnin>** holy smokes
+**\<lurkinandlearnin>** 60% faster than current impl or than pre-BP?
+**\<sarang>** than the 0.13 release code
+**\<suraeNoether>** jeez
+**\<sarang>** that is, 0.13 vs master
+**\<sarang>** as of a few days ago
+**\<suraeNoether>** where did this speedup come from?
+**\<sarang>** Folding in some multiexponentiation operations, as well a host of other voodoo moneromooo can dooo
+**\<sarang>** So we can brag about the next release making txns smaller and faster again :D
+**\<moneromooo>** I did not keep track of which change sped up by how much. I think sarang's single multiexp change is probably the biggest one though.
+**\<sarang>** Let's now discuss NEW WORK
+**\<suraeNoether>** cool!
+**\<sarang>** suraeNoether: your personal updates?
+**\<suraeNoether>** personally, this past week was largely a konferenco administration week for me, contacting speakers and vendors and getting my bank compliant with me
+**\<suraeNoether>** i did research on bulletproofs, linear algebra in cryptography, and our matching paper
+**\<sarang>** I'm sooper excited for this conference
+**\<suraeNoether>** but a lot of my work this week was contacting possible speakers
+**\<sarang>** sounds like we'll have some big names joining us
+**\<suraeNoether>** yes, it's pretty great so far; we are adding more names this week
+**\<sarang>** Any updates on the matching paper suraeNoether ?
+**\<suraeNoether>** my simulations aren't passing unit tests
+**\<suraeNoether>** once they do, i'm making a commit
+**\<suraeNoether>** and then collecting data
+**\<suraeNoether>** so: it's moving forward
+**\<sarang>** excellent
+**\<sarang>** Any questions for suraeNoether ?
+**\<sarang>** OK, I'll go next
+**\<suraeNoether>** oh i had one more thing to bring up
+**\<suraeNoether>** sorry sarang, i don't want to interrupt
+**\<sarang>** np go ahead
+**\<lurkinandlearnin>** is there a list of speakers for the conference?
+**\<suraeNoether>** i found all those old Monero Protocol Standards documents I started writing last year, and I'm wondering if folks still want me to compose the v0.1 versions of these rather short text documents into something to put up on our github
+**\<lurkinandlearnin>** or not official yet?
+**\<suraeNoether>** lurkinandlearnin: check out konferenco.xyz
+**\<suraeNoether>** the benefit of having the standards instead of a single big zero-to-monero document is this:
+**\<suraeNoether>** we can update each one piecemeal and only update it if something has changed. this reduces overhead work on documentation. and if it's on github, anyone can update them, we don't have to go find kurt magnus or koe
+**\<sarang>** FWIW the ZtM doc is on github and can be PRed
+**\<sarang>** but I see the point about modularity
+**\<sarang>** My pessimistic side worries that updates would fall behind, as they already have on ZtM
+**\<lurkinandlearnin>** What aspects of the protocol are covered? Could be something useful to incorporate into the often neglected wiki
+**\<lurkinandlearnin>** as they both sound modular
+**\<suraeNoether>** lurkinandlearnin: essentially similar to the cryptonote standards they released after i reviewed their whitepaper years ago, like this: https://cryptonote.org/cns/cns006.txt
+**\<suraeNoether>** (my whitepaper review would have been moderately better if they wrote those standards before the whitepaper, but hey)
+**\<suraeNoether>** sarang your points are valid
+**\<suraeNoether>** which is why i'm not sure if it's a good idea to devote time to it
+**\<Isthmus>** Wiki is a good idea, specs are a good idea. Having experience as a book editor, people making random PRs is a huge nightmare to text style and continuity and often took 4x as long to polish then if SerHack and I had written ourselves.
+**\<suraeNoether>** okay, how about this
+**\<sarang>** Whatever is made available, whether ZtM or wiki or standards, keeping up to date is the most important aspect IMO
+**\<sarang>** I cringe at "text-rendered math" though...
+**\<Isthmus>** Maybe we should pick one to be the "reference" documentation and the others follow suite?
+**\<sarang>** Who's responsible for maintenance of each one?
+**\<lurkinandlearnin>** Well as long as the version at time of writing is very clear keeping it updated is not so critical
+**\<suraeNoether>** sarang who's responsbile for maintaining anything around here?
+**\<sarang>** lurkinandlearnin: I disagree
+**\<suraeNoether>** how about i just post what i have after making it a little more readable, and if someone wants to run with it they can
+**\<lurkinandlearnin>** nice, but not disastrous. If anything having info about how things used to work out there is also useful.
+**\<suraeNoether>** i can post it on my personal github to avoid cluttering the primary\\
+**\<sarang>** suraeNoether: I think that'd be useful, to get a better sense of scope of audience
+**\<suraeNoether>** sarang: we can always label them clearly DEPRECATED AND NOT USEFUL. but i think it'd be better to have them out there
+**\<sarang>** good point
+**\<suraeNoether>** okay handing it back to sarang
+**\<sarang>** As long as it's clear what can be considered "closer to canonical"
+**\<sarang>** So I've had some testing and minor optimizations to BPs for the next release, as mentioned earlier
+**\<sarang>** Minor work on simulating block size changes to confirm work by Isthmus on scaling etc.
+**\<sarang>** Recording of new Breaking Monero episodes with sgp\_
+**\<sarang>** The usual new lit and project review
+**\<sarang>** and some work on a safe MPC protocol for Bulletproofs for future use
+**\<sarang>** as well as a lot of back-and-forth administrivia on the topics for the Boron upgrade
+**\<sarang>** I am personally in favor of either Boron Betelgeuse or Boron Bellatrix
+**\<sarang>** (as far as names go)
+**\<sarang>** and of course the math for graph matchings, which has been passed back to suraeNoether for simulation data that he is obtaining
+**\<lurkinandlearnin>** Betelgeuse will lead to a schism in the community over pronounciation
+**\<sarang>** precisely
+**\<sarang>** It's like the naming of iPhone X... by making it hard to get right, it forces you to think it's better than you are
+**\<sarang>** humbles us all
+**\<lurkinandlearnin>** "It gets the people going!"
+**\<sarang>** Any questions for me?
+**\<lurkinandlearnin>** what's the next breaking monero topic?
+**\<moneromooo>** Hmm... Lightning network things ?
+**\<sarang>** moneromooo: what questions on that?
+**\<Isthmus>** "Boron borealis" ?? I think there's a Harry Potter character called Bellatrix, which could get confusing with all the HP-themed MimbleWimble names.
+**\<sarang>** lurkinandlearnin: we have several topics in the lineup, to be arranged
+**\<Isthmus>** Also, Breaking Monero = awesome, thanks for all the time going into that series :- D
+**\<moneromooo>** Was anything done or thought about recently about anything monero needs for LN or LN style system ?
+**\<sarang>** moneromooo: some of it was an efficient and fungible way to handle protocol aborts, a la noninteractive refunds
+**\<sarang>** that was quietly tabled as several proposals for interactive refunds were thrown around
+**\<moneromooo>** Ah yes. It would be nice to see a list of things that are needed in monero as building blocks. In terms of parenthesized AND/OR. I always forget. Or never knew.
+**\<sarang>** That's a good point. Having a well-considered status update will be useful for longer-term planning
+**\<sarang>** Does anyone else have updates to share, before we adjourn?
+**\<sarang>** righto
+**\<sarang>** Thanks to everyone for joining
+**\<sarang>** Our current action items:
+**\<sarang>** (a) simulation data for block size proposals, to make a decision before freeze
+**\<sarang>** (b) final review of transaction size reduction PR
+**\<sarang>** (c) meeting to decide on payment ID deprecation (PLEASE attend or comment on github issue if you have an opinion on this, with justification/data)
+**\<sarang>** at ease, soldiers
diff --git a/_posts/2019-01-28-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-28.md b/_posts/2019-01-28-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-28.md
new file mode 100644
index 0000000000000000000000000000000000000000..1daf5d3957dcf68841b6f833b20ca5d978648632
--- /dev/null
+++ b/_posts/2019-01-28-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-28.md
@@ -0,0 +1,311 @@
+---
+layout: post
+title: Logs for the Monero Research Lab Meeting Held on 2019-01-28
+summary: Ongoing work, MRL going to SBC, and miscellaneous
+tags: [community, crypto, research]
+author: el00ruobuob / surae
+---
+
+# Logs
+
+**\<suraeNoether>** allrighty, well, it's 17 UTC
+**\<serhack>** Hi!
+**\<suraeNoether>** howdy everyone
+**\<ardyfy>** HI
+**\<oneiric\_>** ohiyo
+**\<Xeagu>** Hey
+**\<learninandlurkin>** Salutations
+**\<ArticMine>** hi
+**\<suraeNoether>** today, our agenda is here: https://github.com/monero-project/meta/issues/302
+**\<Mochi101>** woohoo!
+**\<suraeNoether>** allrighty, so let's begin with payment ID deprecation
+**\<Mochi101>** Very sad.
+**\<suraeNoether>** my understanding is that some folks are opposed to the proposed timeline for switching over to subaddresses
+**\<Mochi101>** Don't you guys think that such drastic changes hurts Monero adoption?
+**\<Xeagu>** It is new information to me that this was not already default
+**\<xiphon>** Mochi101: payment id is actually what "hurts Monero adoption"
+**\<xiphon>** ^ standalone one
+**\<suraeNoether>** mochi101 what drastic change are you referring to? deprecating payment IDs? or enforcing subaddresses?
+**\<Mochi101>** Both actually.
+**\<learninandlurkin>** Drastic changes is what Monero is all about. 6 month forks and whatnot.
+**\<ArticMine>** I am in favor of this, the only possible issue I see is timing on which I am neutral
+**\<suraeNoether>** in my opinion, switching to a system with fewer moving parts with fewer ways for users or wallet developers to accidentally screw up, this is a net win for monero users, the ecosystem in general.
+**\<gingeropolous>** ^^
+**\<Mochi101>** Yes, Monero feels like a really high maintenance, needy girlfriend sometimes.
+**\<suraeNoether>** i don't know about you, but "idiot proof" cryptography is sort of a myth, but it'd be really really great if we could take incremental steps toward systems with fewer complications glued on top just to make it work
+**\<Xeagu>** In the unknown future, will Monero no longer require network upgrades every 6 months?
+**\<suraeNoether>** xeagu i believe we are intending on keeping 6 month network upgrade schedules for the foreseeable future, with the intention of \*eventually\* slowing them down
+**\<suraeNoether>** i don't know what timescale "eventually" means here, practically, though. fluffypony has mentioned it before but I don't recall the timescale
+**\<Xeagu>** Do you think a timeline would help those with concerns about that activity hurting adoption?
+**\<learninandlurkin>** The unknown future is unknown
+**\<silur>** I aggree that in the anctient security vs UX war we need to stick with security
+**\<silur>** and moving/changing parts is a golden rule in crypto
+**\<silur>** even if it's more surface for users to screw up
+**\<suraeNoether>** ArticMine: thank you for supporting the change. i'm with you on both timeline and supporting the upgrade. i'm asking if anyone here has specific timeline objections they want to bring up; last I recall, sgp\_ had a great chart, but perhaps the discussions have changed a bit since then?
+**\<dEBRUYNE>** UX issues stemming from payment IDs are predominantly caused by the long, unencrypted payment IDs. Thus, imo, it's imperative that we remove those
+**\<suraeNoether>** ^^
+**\<Mochi101>** As far as I know there's not even any real documentation on subaddress generation, identifying the last index which has been used, etc.
+**\<Mochi101>** That's pretty bad when you're going to force it.
+**\<sgp\_>** Mochi101: https://github.com/monero-project/meta/issues/299
+**\<sgp\_>** lots of details there, including a basic upgrade guide for services
+**\<suraeNoether>** thanks for the link to the previous PayID discussion, sgp\_ ! i am bookmarking that rn
+**\<sgp\_>** services have nearly half a year to upgrade, which is reasonable given the requirements. We have spoken to exchanges and payment processor services who think the timeline is aggressive but realistic
+**\<sgp\_>** Mochi101: the logs for the meeting are also available at the same link
+**\<suraeNoether>** sgp\_: cool! personally, I think this is a win for monero users in terms of privacy, a win for developers in terms of elegance, and a win for the ecosystem in terms of efficiency
+**\<sgp\_>** I recommend you read them
+**\<Xeagu>** I admit I don't understand how subaddresses work
+**\<suraeNoether>** I don't want to speak for sarang; perhaps when he gets back he can jump in and provide an opinion.
+**\<Xeagu>** There is a need in the market for distributed education
+**\<suraeNoether>** Xeagu: the main idea is you take your wallet address (A,B) and you generate a family of addresses deterministically all sharing the same view key, and allowing you to mass-scan all the subaddresses simultaneously for incoming transactions
+**\<suraeNoether>** it's a little more complciated than that because they don't \*actually\* share a view key
+**\<Mochi101>** Thanks. But you're only seeing this from your "in the loop" perspective. I looked for information about this and couldn't find any in the places that I expected them to be. Really people using Monero should not have to search through GitHub to find this stuff. If it's a major issue like this it should be front and center on something like getmonero.org
+**\<suraeNoether>** but they can all be \*scanned\* with a single view key
+**\<Xeagu>** Yes I am confused on the order that subaddresses are selected during generation
+**\<Xeagu>** If they are deterministic, no?
+**\<gingeropolous>** is there anything research-y about payment IDs / encrypted / subaddresses at this point? I mean, its pretty solid that anything except subaddresses is sub-optimal, right?
+**\<suraeNoether>** you use deterministic nonces while hashing, so they appear random but always come up to be the same
+**\<sgp\_>** Xeagu: read this: https://medium.com/@anhdres/how-moneros-accounts-and-subaddresses-work-in-monerujo-4fa7df0a58e4
+**\<selsta>** Mochi101: You should subscribe to the newsletter.
+**\<dEBRUYNE>** Mochi101: It was announced on the mailing list
+**\<sgp\_>** Yes, please join that. It's essential for staying up-to-date
+**\<Xeagu>** Alright so basically I need to read through Mastering Monero again
+**\<suraeNoether>** gingeropolous: yeah. this is a question (subaddresses) about key infrastructures. not really in doubt that subaddresses are objectively superior in terms of engineering and in terms of simplicity. keeping around old systems for no good reason is not going to help adoption.
+**\<suraeNoether>** also as far as I understand it, the MRL contributors sgp and knaccc are both working on documentation
+**\<gingeropolous>** right. it just seems at this point we gotta bite the bullet and go through the suck.
+**\<suraeNoether>** we can continue this conversation after the meeting
+**\<Xeagu>** Subaddresses mean you only really need to memorize a single wallet seed, as I understand it.
+**\<sgp\_>** yes Xeagu, and best to table this discussion imo
+**\<Xeagu>** Let's move on
+**\<suraeNoether>** let's move along to the oh-so-contentious block size scaling discussion
+**\<suraeNoether>** articmine is currently validating some cost analyses by sarang
+**\<OWLisFLOWN>** Sup n00bs
+**\<suraeNoether>** i whipped up two ideas, one wacky and one not for block size debate, and i'll be contributing these two ideas to the mix to see about how it all fits together
+**\<suraeNoether>** in terms of cost analyses
+**\<Xeagu>** What are the two ideas?
+**\<ArticMine>** I presented my overall proposal
+**\<suraeNoether>** my first idea is a simple low-pass filter, and my complicated idea is inspired by some discontinuous reset models from neuroscience, which sounds fancy, but is in no way "modeling brains on the blockchain" or anything like that, please do not run away with my words
+**\<suraeNoether>** ArticMine: yeah, i thought you and sarang were working together to make sure cost analyses were apples-to-apples comparisons?
+**\<ArticMine>** https://paste.debian.net/hidden/556a3a8a/
+**\<suraeNoether>** aha!
+**\<suraeNoether>** thanks articmine
+**\<suraeNoether>** that's articmine's proposal
+**\<Xeagu>** Interesting okay. Can you explain the low-pass filter? I'd like to discuss the brains on the blockchain idea later.
+**\<ArticMine>** There was one addition: We can use LongTermBlockWeight as opposed to BlockWeight in the fee calculation
+**\<suraeNoether>** xeagu essentially all our proposals revolve around discrete-time dynamical systems, including my discontinuous reset idea. so "how to update next\_max\_block\_size as a function of previous block sizes... so that the blockchain doesn't get caught in a feedback loop and blow up for a determined and moderately wealthy attacker?"
+**\<Xeagu>** This is trying to determine future dynamic block size scaling?
+**\<suraeNoether>** yep.
+**\<silur>** wait
+**\<silur>** I have a paper on this issue
+**\<suraeNoether>** great!
+**\<suraeNoether>** please link!
+**\<silur>** it's originally for PoS
+**\<silur>** but does address the problem
+**\<suraeNoether>** i believe articmine's approach is good in the sense that it forces an attacker attempting to force bloat to drag out an attack over a long timescale in order to have a decent influence, which costs more and more money.
+**\<silur>** of keeping this wealth blowup in check
+**\<silur>** https://arxiv.org/abs/1809.07468v2
+**\<suraeNoether>** interesting, thank you. i believe someone had an idea where miners vote on the max block size for the next N blocks using proof of work, but i haven't looked further into it yet
+**\<suraeNoether>** wb sarang
+**\<Xeagu>** I am not familiar with ArticMines proposal
+**\<suraeNoether>** xeagu he linked it a moment ago, and sarang has been running simulations and comparing costs
+**\<silur>** this one has a formula for how to calculate the next reward based on the current parameters
+**\<silur>** maybe we can generalize it for blocksize?
+**\<Xeagu>** I need it in ELI5 terms
+**\<ArticMine>** interesting, thank you. i believe someone had an idea where miners vote on the max block size for the next N blocks using proof of work, but i haven't looked further into it yet] <--- This is one of many failed Bitcoin proposals
+**\<moneromooo>** As long as we finalize ArticMine's proposal soon, before the fancy new stuff gets worked on :)
+**\<Xeagu>** How does the dynamic block size change from its current state?
+**\<suraeNoether>** ArticMine: also good to know
+**\<suraeNoether>** xeagu right now
+**\<sarang>** The newer proposals do away with the idea of a single median
+**\<suraeNoether>** we allow next max block size to be 2\*Median(last N blocks)
+**\<suraeNoether>** i forget N
+**\<moneromooo>** Xeagu: https://paste.debian.net/hidden/556a3a8a/
+**\<moneromooo>** 100000
+**\<sarang>** Details that have been previously reviewed can probably be discussed more deeply after meeting, IMO
+**\<Xeagu>** moneromooo: that's too high level for me
+**\<moneromooo>** And 1.4 IIRC, not 2.
+**\<Xeagu>** I'll review other notes sure
+**\<suraeNoether>** moneromooo: oh! that's good :D
+**\<suraeNoether>** xeagu i'll get you after the meeting
+**\<sarang>** atm, I am waiting to see what cost details are added by ArticMine to ensure we understand the relative cost of bloat under the different options
+**\<Xeagu>** Okay
+**\<suraeNoether>** basically: block size scaling is still under discussion, we are working on formalizing articmine's proposal and comparing it to our present proposal as well as at least one other proposal.
+**\<suraeNoether>** and i think sarang and i can collaborate on a technical note describing all this
+**\<suraeNoether>** moving along to MRL 11's status update: MRL 11 is essentially about traceability and linkability in Monero, and comparing techniques across multiple blockchains like Zcash + Monero together
+**\<suraeNoether>** if you guys have seen matthew green and binaryfate and fluffypony sparring on twitter about ring sizes compared to the shielded pool in zcash
+**\<suraeNoether>** this is that
+**\<Xeagu>** Zcash doesn't scale
+**\<silur>** ah :D
+**\<suraeNoether>** the current status is that sarang passed it back to me more than a week ago, and i've been tinkering with simulations
+**\<ArticMine>** My proposal uses the current 2x maximum for the short term median and 1.4x for the long term median
+**\<Xeagu>** You can't let every transaction be shielded without huge data storage
+**\<suraeNoether>** i want to simulate something like the following, and it's quite challenging to formalize this (i'm bringing my hangup to the crowd so you guys know what i'm stuck on)... I want to create a formal statistical hypothesis, and it's eluding me...
+**\<suraeNoether>** essentially, i want to capture the EABE scenario that started this whole paper last year
+**\<suraeNoether>** and churn
+**\<Xeagu>** EABE scenario?
+**\<sarang>** Poisoned outputs
+**\<Xeagu>** Oh got it
+**\<suraeNoether>** I want to generate a random blockchain (somehow) and embed within it the spending behavior masking "churn" between receiving a possibly "marked note" and then later trying to cash it out at a KYC/AML exchange
+**\<suraeNoether>** then i want to apply our matching technique to see the probability that this behavior is caught, if someone is looking for it
+**\<Xeagu>** But as I understand if you just show view key, the exchange will accept it
+**\<suraeNoether>** xeagu that's the final vertex in the transaction graph
+**\<suraeNoether>** there may be many intermediate vertices as you churn
+**\<suraeNoether>** most importantly, we need somehow to gauge the entire confusion table; false positives, false negatives, true positives, and true negatives
+**\<Xeagu>** Like how far back do exchanges care about poisoned outputs?
+**\<sarang>** unknown
+**\<suraeNoether>** and i can do this \*under certain hypotheses\* but i can't do it in general. all i really i want is a practical comparison of our technique to a real world scenario like a miner trying to hide that he's depositing a mined coin on an exchange
+**\<sarang>** You should conservatively assume "all the way back"
+**\<sarang>** Anyway, feels like we're getting off topic somewhat
+**\<Xeagu>** Was regarding MRL 11
+**\<Xeagu>** Traceability comparison
+**\<suraeNoether>** so, to summarize MRL 11: we have an algorithm, we have timing estimates, we are working on simulations and comparisons of our technique across multiple blockchains at once, and we are basically gearing up to figure out how many churns is enough... or... alternatively... we are gearing up to figure out how to show the depth of the wastefulness of having a massive anonymity set like the whole zcash shielded
+**\<suraeNoether>** pool
+**\<suraeNoether>** sarang: think that was an okay summary? i don't want to speak for you
+**\<sarang>** Yes, the computational bounds are the most interesting part IMO
+**\<suraeNoether>** yeah, same actually
+**\<sarang>** they set a framework for analyzing certain behavior
+**\<suraeNoether>** the interesting thing to me is we were able to put lower bounds on how fast an attacker can generate a "guess" at a possible spend history
+**\<suraeNoether>** bad news: it's pretty fast. good news: there are lots and lots of possible spend histories, like cryptographically many
+**\<suraeNoether>** how much is the practical security compared to a zk-snark scenario? we'll find out
+**\<sarang>** So you earlier discussed block size scaling (waiting on cost analysis)... did I also miss anything on output selection?
+**\<suraeNoether>** spoiler: if both blockchains exist together at the same time, one with an opt-out transparent pool and both with users interacting at KYC/AML exchanges... then security on both are wildly compromised
+**\<suraeNoether>** sarang eek I forgot to add output selection to the agenda, that's my bad
+**\<sarang>** OK, is now a good time for this?
+**\<suraeNoether>** perfect time actually
+**\<sarang>** Great
+**\<Xeagu>** It's not on the agenda but I wanted to make sure we discussed the rumor of ASIC/FPGAS on the network.
+**\<sarang>** moneromooo had asked me earlier about reviewing our windowing approach to gamma selection
+**\<sarang>** He had an idea about further weighting selection probability of a block based on output count
+**\<sarang>** with a possible goal of reducing the coinbase-to-non-coinbase ratio in rings to that of the whole chain
+**\<suraeNoether>** xeagu we'll get to that in a sec, thanks for reminding me :\\
+**\<sarang>** e.g. 6-10% of outputs are coinbase, so 6-10% of a ring should be as well
+**\<sarang>** moneromooo can explain it better, but the idea would be to take the gamma probability of block selection and further weight by the block's output count, and then uniformly select within that block
+**\<sarang>** I'm working up some code based on chain stats
+**\<sarang>** but I'll put it out there for comment
+**\<suraeNoether>** sarang #actually
+**\<suraeNoether>** the distribution in the ring should be "whatever the probability that the next transaction is a coinbase output."
+**\<Xeagu>** I think miners churning newly mined coins would help against poisoned outputs
+**\<suraeNoether>** so if miners typically hodl for long long long times, then mimicing the distribution of the outputs that care coinbases will drastically over-sample the coinbase outputs.
+**\<suraeNoether>** xeagu i agree
+**\<gingeropolous>** <sarang> e.g. 6-10% of outputs are coinbase, so 6-10% of a ring should be as well >>>>> but 99% of coinbase outputs are owned by about 15 people
+**\<suraeNoether>** i think a lot of miners churn in order to mask that they are mining
+**\<suraeNoether>** gingeropolous: exactly!
+**\<sarang>** I know, but we have no good metric for "how many coinbase in a ring is ok"
+**\<suraeNoether>** unfortunately we don't really have a way of estimating how often any given subsets of our blockchain are spent
+**\<sarang>** Currently it's 1-3 outputs per ring on average that are coinbase
+**\<moneromooo>** The idea I had is meant to (I think) make the selection process match the gamma from an ideal blockchain (ideal being, every block has the same number of outputs).
+**\<moneromooo>** And indeed, in that particular case, the two distributions match.
+**\<moneromooo>** The idea has two steps:
+**\<sarang>** Nice, did you run sims?
+**\<moneromooo>** - for each block, calculate its probability of being picked by the gamma distribution pick
+**\<moneromooo>** - for each block, multiply that number by the number of outputs in that block
+**\<moneromooo>** Then you just pick a random block from those weights using a discrete distribution.
+**\<moneromooo>** I did not run sims, because I do not know how to calculate the first step.
+**\<suraeNoether>** MOO
+**\<suraeNoether>** you brilliant bastard
+**\<suraeNoether>** you want to know why that works?
+**\<sarang>** moneromooo had pointed out earlier that this also solves the issue of a fixed window size
+**\<moneromooo>** Well, I see how it'd work by, er... intuition really. Why does it work ?
+**\<suraeNoether>** you are estimating an empirical distribution: when you multiply that number by the number of outputs in the block, you are computing the expected number of outputs to be selected from that block. then you built a histogram and selected from that!
+**\<sarang>** Yeah
+**\<suraeNoether>** it's cool
+**\<suraeNoether>** expectation as a linear operator
+**\<suraeNoether>** fun stuff
+**\<suraeNoether>** \*ahem\*
+**\<sarang>** the scaling of coinbase outputs in this case is also independent of the gamma distribution, which I find neat
+**\<suraeNoether>** very frequentist. hem hem
+**\<suraeNoether>** yeah, you could use this with any underlying hypothetical distribution
+**\<sarang>** I'm confirming that it does so, and writing up some sims to convince myself of it
+**\<suraeNoether>** \\me eats oatmeal
+**\<sarang>** kudos moneromooo, it's a clever approach that fixes the issues with windowing
+**\<gingeropolous>** so there's still a probability that multiple coinbases will be selected, but because tiny blocks have low probability, we should expect less outputs selected from tiny blocks?
+**\<suraeNoether>** it actually fixes several other things i'd been thinking about
+**\<suraeNoether>** it's a great framework.
+**\<moneromooo>** Thanks. Still needs a way to compute the first number. I fear it might involve integrals.
+**\<Xeagu>** I don't understand :/
+**\<sarang>** moneromooo: probably not =p
+**\<suraeNoether>** gingeropolous: yeah, exactly. each output has a gamma age, and then you select from all outputs. rather than selecting an output age from a gamma and then selecting from all the outs with that age. subtle flipping of the order of things
+**\<sarang>** I believe it should reduce the ring ratio to that of the whole chain
+**\<Xeagu>** I don't know what gamma means
+**\<sgp\_>** In the most extreme case, we can say 0 coinbase are necessary and force independent miners to churn their received funds if they care. Pools don't care and are the main cause of this debate. But there doesn't seem to be enough support for this, and it comes with other tradeoffs. I just think it's important to keep mentioning
+**\<moneromooo>** A particular random distribution.
+**\<sarang>** the way we select ring members using math Xeagu
+**\<gingeropolous>** Xeagu, you can think of gamma as a droopy triangle
+**\<suraeNoether>** xeagu there is a long statistical background on the gamma distribution. we'll catch you up after the meeting
+**\<gingeropolous>** right triangle, 90 degrees on the right side. the hypotenuse is the droopy side
+**\<sarang>** sgp\_: we can enforce coinbase-only rings as a first churn, but that doesn't solve the heuristic of "coinbase are bad"
+**\<sarang>** it just moves it along the transaction graph a teeny bit
+**\<sarang>** so I feel ya
+**\<suraeNoether>** you flip a coin until you get a heads up and right down the number of flips. then you do that 10 times. then you add those wait-times-until-heads-up together
+**\<sgp\_>** sarang: this would just accept "coinbases are bad" and not touch them whenever possible
+**\<Xeagu>** So if gamma is a process (verb) how is it acting as an adjective modifying a noun (age)?
+**\<gingeropolous>** i dunno what parameters we use, but https://en.wikipedia.org/wiki/Gamma\_distribution#/media/File:Gamma\_distribution\_pdf.svg
+**\<gingeropolous>** i'd guess we look like the red line
+**\<suraeNoether>** and then you ask "what is the probability that i got wait times of 3, 2, 0, 1, 1, 0, 1, 2, 1, 0?" that's essentially a gamma distribution
+**\<gingeropolous>** Xeagu,
+**\<sarang>** The heuristic would move from "coinbase in a ring are decoys" to "outputs generated in a coinbase-only ring are decoys"
+**\<suraeNoether>** sarang i'm not sure i follow that
+**\<sarang>** unless you convince miners to churn more out of the goodness of their pooled hearts
+**\<suraeNoether>** oh i think i follow you
+**\<sarang>** Right now you might throw out all coinbase ring members as decoys
+**\<sarang>** Now you look back one step, and throw out an output generated from an obvious coinbase churn
+**\<sarang>** You gain very little from this
+**\<suraeNoether>** yeah, i think i follow yoiu
+**\<sarang>** So I like the idea of shooting for a ring member ratio matching the chain
+**\<sarang>** and this weighted approach should do that for us
+**\<sarang>** to be confirmed by sanity-check sims!
+**\<suraeNoether>** okay, so the output selection method proposed by moneromooo is actually a really clever way of computing expectations, and as a consequence, gives us a better output selection method. we should glance through the code, but i'm happy with that
+**\<suraeNoether>** FPGA/ASIC stuff
+**\<sarang>** Neat
+**\<suraeNoether>** let's move along
+**\<suraeNoether>** i hear some nonce distributions are non-uniform
+**\<sarang>** and they recently changed as of the new year-ish
+**\<suraeNoether>** fun
+**\<suraeNoether>** so, i'm not really prepared to talk about monero POW and asic-resistance right now, tbqh
+**\<suraeNoether>** i happened upon some reading this weekend on sponge constructions, so i'm currently on the path toward learning more about hash functions and pseudorandom functions
+**\<suraeNoether>** but i don't have any thoughts i want to make public right now
+**\<suraeNoether>** sarang?
+**\<suraeNoether>** (i'm not keeping anything from anyone either, I harbor no secret opinions on this either)
+**\<sarang>** I have been working on sims relating to output selection and block size, and continue side work on bulletproofs MPC and related things
+**\<sarang>** I'll be attending the Stanford academic crypto conference this week
+**\<suraeNoether>** Yeah, sarang and endogenic and i and isthmus will all be there
+**\<silur>** \*not envy\*
+**\<suraeNoether>** CONVENIENTLY i found my LAST FOUR MRL shirts, so you know
+**\<suraeNoether>** i'll be forcing everyone to wear them for a photo
+**\<sarang>** Does anyone else have work to share before we review action items?
+**\<Xeagu>** I have to go
+**\<suraeNoether>** i have been doing some reading on alternatives to ring signatures
+**\<Xeagu>** Great meeting everyone
+**\<suraeNoether>** i plan on writing up a technical note summarizing different options in different cryptographic hardness settings, timing and space comparisons
+**\<learninandlurkin>** Alternatives without huge resource drain?
+**\<suraeNoether>** learninandlurkin: so, some of that is tricky
+**\<sarang>** that's always the kicker
+**\<suraeNoether>** for example, i came across some short-integer-solution methods with lattices that are FAST AS HECK but HUGE
+**\<silur>** oh yes
+**\<suraeNoether>** the tradeoff isn't there yet, but it's worth summarizing it all
+**\<silur>** my favorites
+**\<silur>** they are also good for accumulators
+**\<silur>** I have some demos on that
+**\<silur>** been working with SIS for long
+**\<suraeNoether>** silur ooh, i'd love to see a link of some sort
+**\<silur>** I've got really into noncommutative crypto recently
+**\<suraeNoether>** so i'll be summarizing i think four papers in the coming days, to communicate some of the options we have to the community
+**\<silur>** it feels like a graveyard because except for the primitives everything is broken
+**\<sarang>** Action items for this week?
+**\<silur>** but I asessed all attacks and stuff that are still holding in the recent months
+**\<silur>** main focus on zk stuff now
+**\<sarang>** I am looking forward to ArticMine's sim code updates to reflect rational miner costs, which will allow us to assess our options for next upgrade
+**\<suraeNoether>** my action items are: matching simulations and hypothesis testing, and my alternatives-to-ring-signatures-aren't-much-better technical note
+**\<learninandlurkin>** I'll look forward to that suraeNoether. With ringsigs being our main weakness and also the main missing component of Grin (as compared to XMR) I think this are of research will have big implications.
+**\<silur>** ringsigs are our main weakness?
+**\<silur>** what happenned with RTRS?
+**\<sarang>** It remains an option, but one that requires a lot of overhauling for still being ring sigs :.
+**\<sarang>** :/
+**\<suraeNoether>** silur: sarang has gotten them to be suitably fast with multiexponentiation so that we could, say, use ring sizes up to, say, 20-30. however, there are some other sublinear schemes that are available, each with their own trade-offs, which is why i'm writing my paper
+**\<silur>** wow
+**\<suraeNoether>** i was hoping that once we broke a certain speed barrier, the path forward would be a no-brainer
+**\<silur>** okay, I'll be waiting for it
+**\<silur>** the paper I mean
+**\<suraeNoether>** but we have certain issues we're dealing with and it's not totally clear whether overhauling the system for such a small ring size boost would be worth it if there could be another option with a relatively bigger boost eventually
+**\<sarang>** well said
+**\<suraeNoether>** replace that last word "eventually" with "presently"
+**\<suraeNoether>** cool, /meeting