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

Logs for the Community (2018-02-03 & 2018-02-17), Dev (2018-02-11), and Research (2018-02-05 & 2018-02-12 & 2018-02-19) meetings

Browse source 
add research tag
This commit is contained in:
dEBRUYNE-1 2018-02-20 17:13:06 +01:00
parent 0e1cfc4557
commit f7da2c03a3
No known key found for this signature in database
GPG key ID: B9145F6EBFA81C32
6 changed files with 1527 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

176
_posts/2018-02-03-logs-for-the-Community-meeting-held-on-2018-02-03.md Normal file
View file

@ -0,0 +1,176 @@
---
layout: post
title: Logs for the Community Meeting Held on 2018-02-03
summary: Community highlights, Monero Integrations, Monero outreach initiative, Forum Funding System updates, RFC-HWALLET-1, Localization workgroup, open ideas, and miscellaneous
tags: [community, crypto]
author: dEBRUYNE / fluffypony
---
# Logs
**\<sgp>** Meeting time!
**\<sgp>** 0. Introduction
**\<sgp>** We would like to welcome everyone to this Monero Community Meeting!
**\<sgp>** Link to agenda on GitHub: https://github.com/monero-project/meta/issues/170
**\<sgp>** Monero Community meetings are a discussion place for anything going on in the Monero Community. We use meetings to encourage the community to share ideas and provide support.
**\<sgp>** 1. Greetings
**\<xmrscott[m]>** Salutations
**\<ErCiccione>** Hi
**\<rehrar>** This guy
**\<sgp>** @pigeons the mattermost relay is down
**\<sgp>** 2. Community highlights
**\<sgp>** For a great weekly summary, please read the Monero Observer: http://monero-observer.com/
**\<sgp>** 3. Monero Integrations improvements
**\<sgp>** cryptochangements asked to speak for a few minutes about improvements they have made to existing integrations.
**\<cryptochangement>** ok i just got here
**\<cryptochangement>** didnt know mattermost was down
**\<sgp>** perfect timing :)
**\<cryptochangement>** okay so basically, I just wanted to share that I have improved on the wordpress plugin from serhack's last FFS and made it easier for merchants to accept Monero
**\<cryptochangement>** basically it allows people to use their viewkey with a block explorer instead of an rpc waller
**\<cryptochangement>** \*wallet
**\<cryptochangement>** here is the reddit post I made with a video demo: https://www.reddit.com/r/Monero/comments/7tkpfu/accepting_monero_with_monerointegrations_just_got/
**\<cryptochangement>** and several more new merchants have already started using the upgraded version
**\<cryptochangement>** there is still some concern about using a node that is not yours to validate 0 confirmation transactions which I'm still looking into, but IMO you should really just stick to the "small amounts only" rule when accepting 0 conf transactions.
**\<cryptochangement>** Any questions?
**\<cryptochangement>** otherwise we can move on :)
**\<sgp>** Thanks cryptochangement
**\<sgp>** 4. Monero outreach initiative
**\<sgp>** Rehrar asked to discuss his idea about an outreach initiative for this workgroup.
**\<rehrar>** yeah, and my IRC is being stupid. sec.
**\<rehrar>** I'll just type from MM.
**\<sgp>** Ok, looks like Mattermost relay is back up
**\<cryptochangements>** ok cool
**\<rehrar>** Alright, so the basic idea of this Outreach, is that we get a small subgroup of interested community members to make a list, identifying other exciting open-source projects. They don't have to be crypto or privacy created. Mostly stuff that is trying to change the world.
**\<rehrar>** We then do what I'm calling a
**\<rehrar>** 'Monero bomb' of this project (sorry, pressed enter by accident)
**\<rehrar>** Where a bunch of us Monero people go to them, see what they need, and do it. Things like translations, website work, infographics, whatever.
**\<rehrar>** Then we disappear into the night. They've just got "Monero'd"
**\<rehrar>** The ultimate goal of something like this being to build bridges of relationship with the open source community at large, and solidify Monero's place there.
**\<rehrar>** In its purest form, open-source is a more-or-less altruistic way to see the world change, and empower people with software, rich and poor.
**\<rehrar>** In its purest form, it's not about the money.
**\<rehrar>** Cryptocurrency is very strange, in that, for most projects, it's all about the money, despite being open source. It's a weird bastardization. But you see with the launch of Bitcoin, it was about changing the world by providing a better money, not about making money.
**\<rehrar>** I like to think Monero subscribes to being like that. We're not about getting rich. We're about changing the world, and there's a lot of other projects that are trying to do that in small ways too
**\<ArticMine>** This seems to me to e a very worthwhile project
**\<rehrar>** Monero can show them some love, get our word out there and help them spread theirs at the same time.
**\<rehrar>** We can help them get set up with Monero donations, etc. etc. etc. What we can accomplish for them is only limited by the skills of the volunteers we have.
**\<cryptochangement>** sounds good, it would be awesome if we could get the coordination for that
**\<rehrar>** This also gives a project for the many people who want to help Monero, but don't know how cuz they can't code.
**\<rehrar>** Either way, that's my idea.
**\<rehrar>** If we like it, I can start work on it.
**\<ArticMine>** Of course we can look at Monero as a multi-billion dollar crypto-currency with an elaborate security model based entirely upon software freedom
**\<cryptochangement>** I for one like it
**\<cryptochangement>** looks like a small crowd today
**\<sgp>** @rehrar I think the most difficult part would be finding enough participants
**\<rehrar>** This is true.
**\<rehrar>** Which is kind of sad, since Monero community is so big, but that's the way it goes with anything, I think.
**\<cryptochangement>** I think we could easily find enough people in time, but coordinating volunteers to do stuff like that all together in a short-ish amount of time would probably be the bigger challenge
**\<sgp>** Maybe a mailing list would help more than subreddit posts. Not sure
**\<ArticMine>** There is also a lack of awareness in the Monero community as a whole as to the critical role Free Software and software freedom play in Monero
**\<rehrar>** We can have a 'sign up sheet' where people sign up to receive emails about stuff. They say their skills, and once a month we have a new project to help.
**\<cryptochangement>** the problem with a r/ post is that most people over there are just scrolling by with short attention spans
**\<rehrar>** \^ ArticMine
**\<rehrar>** Most people don't really understand open source as a whole. They know Monero IS open source, but they don't know the ideals of open source, and how it tries to change the world
**\<cryptochangement>** the 'sign up sheet' sounds like a good idea tho
**\<sgp>** @rehrar sounds good, as long as you include clear projects for beginners to work on
**\<rehrar>** Then maybe we can have a sticky in the Community subreddit of the project we're helping this month
**\<rehrar>** final though from me:
**\<cryptochangement>** the community subbreddit is nice, but pretty small :/
**\<rehrar>** even if all this accomplishes is tiny bits of help (financial or otherwise) toward a project, the other thing it accomplishes is spreading the word of open-source as a whole to our community, and generating awareness for other projects that some in the community might find useful
**\<rehrar>** it's pretty easy to 'catch the vision' of Monero, when you catch the vision of open source as well.
**\<ArticMine>** ^^ This is critical
**\<rehrar>** In the end, isn't that the goal of the Community workgroup?
**\<rehrar>** We try to make a better community
**\<rehrar>** and a better community, is a community that 'gets it'
**\<sgp>** Yes, at least imo
**\<ArticMine>** It can be part of the role of the Monero Community
**\<rehrar>** so it makes sense that our subreddit and stuff is small
**\<rehrar>** cuz not many people 'get it' ;)
**\<sgp>** @rehrar part of it is me mostly using the subreddit only for announcements
**\<rehrar>** Either way, once again, it will make an outward focus for Monero instead of just an inward ones, which will set us apart from other crypto projects.
**\<rehrar>** *bows* thank you
**\<cryptochangement>** *applauds*
**\<rehrar>** (my rant for the meeting)
**\<ArticMine>** To me it is a recognition o the debt Monero own the FLOSS communities
**\<ArticMine>** owes
**\<sgp>** Yeah, I think it's a good project to have
**\<serhack>** hi :)
**\<sgp>** Anything else? What do you need to get started @rehrar?
**\<rehrar>** I guess some volunteers to work with me to start compiling a list. :)
**\<rehrar>** I'll make a Taiga for it.
**\<sgp>** ok cool, look forward to seeing how this project evolves
**\<rehrar>** also check out the new refreshed getkovri.org website and tell me if anything is broken for you on mobile, desktop, or tablet :D
**\<cryptochangement>** I'd be glad to volunteer
**\<serhack>** I like your idea rehrar
**\<rehrar>** I like my idea too serhack ;)
**\<cryptochangement>** so you got at least 1 or 2 already :p
**\<sgp>** 5. FFS updates
**\<sgp>** There are several FFS updates.
**\<sgp>** a. Localization workgroup Q&A
**\<sgp>** Erciccione asked to reserve some time for a localization workgroup Q&A.
**\<ErCiccione>** thank you sgp i have a couple of things to say
**\<ErCiccione>** first of all i wanted to apologize to the community, I'm having some personal problems since january. This caused me to work less than i wanted to (and less than what i promised in my ffs) for the localization workgroup
**\<ErCiccione>** this means i'll recover that time on march (reclaiming the third milestone one week later)
**\<ErCiccione>** but i have also some good news :)
**\<ErCiccione>** thanks to rehrar's patch getmonero.org is now ready to be localized, i already set up a guide on taiga and can be found here: https://taiga.getmonero.org/project/erciccione-monero-localization/wiki/translating-monero-website
**\<ErCiccione>** very soon i will upload on github the itlaian translation, so translator can use that as example for their Pull Requests. Also
**\<rehrar>** woohoo!
**\<serhack>** that's nice :)
**\<ErCiccione>** i will publish this evening or tomorrow a reddit post asking for translators, since also getkovri was just refreshed and need to be checked and updated. The GUI is going great btw
**\<ErCiccione>** a lot of translators, and if we are lucky we could get even 3 more translations before the code freeze
**\<cryptochangement>** awesome
**\<ErCiccione>** this is everything coming in my mind right now, the reddit post will be more verbose..if anybody has any question,, here to answer :)
**\<cryptochangement>** btw @ErCiccione i'm about to squash commits for that french GUI update so it should be ready to merge soon
**\<ErCiccione>** great, thanks cryptochangement, will leave my final review after the squash
**\<sgp>** Thanks ErCiccione
**\<sgp>** @michael you ready?
**\<ErCiccione>** thank you guys
**\<sgp>** b. RFC-HWALLET-1 project progress
**\<michael>** Almost.
**\<michael>** On the road problems.
**\<rehrar>** how much time you need?
**\<michael>** Five minutes.
**\<sgp>** Ok, we can move to open ideas time until you are ready. Just jump in whenever
**\<sgp>** I have an thought!
**\<sgp>** I'm surprised we haven't discussed the possible overlap between /r/MoneroCommunity and /r/moonero before. Most large communities have fun making content (eg: dogecoin)
**\<cryptochangement>** *waits suspensfully for sgp's thought*
**\<cryptochangement>** thats an interesting way of looking at it
**\<sgp>** Would encouraging people to make memes encourage people to contribute in other ways? Are we actually harming the community by having these two groups separate?
**\<cryptochangement>** tbh i dont see how making memes will turn into other contributions
**\<sgp>** It just encourages light-heartedness and lowers the barrier for initial contributions
**\<michael>** Can only get a hotel network connection on my phone.
**\<cryptochangement>** its an interesting idea but it might just end up as clutter
**\<michael>** We had a hardware team meeting since the last community meeting.
**\<michael>** For which there are minutes.
**\<michael>** We're working on a new generation prototype, which will integrate one or more new secure elements.
**\<serhack>** Private elements too?
**\<msvb-mob>** Finally online, with a charged battery.
**\<msvb-mob>** serhack: The secure elements lock secrets away from rogue firmware.
**\<msvb-mob>** serhack: I don't know what a private element is.
**\<serhack>** Monero is focused on privacy, I think the hardware wallet should be focused on the same goal
**\<rehrar>** it is, serhack, no worries
**\<rehrar>** the secure element is an actual piece of hardware
**\<serhack>** Right.
**\<ArticMine>** and how open in the hardware? back to the FLOSS question?
**\<msvb-mob>** The hardware uses common parts, passive resistors, capacitors, and active LDO (power), MOSFET (transistors), and the more complex but also common MCUs and ICs.
**\<msvb-mob>** All design, including schematic and layout, is licensed according to the CERN license.
**\<msvb-mob>** We have rejected all NDA (nondisclosure agreements) and have no secret contacts, so this is quite Opensource. In fact even our process (project management and other docs) is.
**\<msvb-mob>** ArticMine: Sound okay to you?
**\<msvb-mob>** Any other hardware team questions?
**\<ArticMine>** Yes this avoids proprietary attacks
**\<sgp>** Thanks @msvb-mob for your update
**\<msvb-mob>** ArticMine: Documents state 'copyright The Monero Project.'
**\<msvb-mob>** sgp: You're welcome.
**\<ArticMine>** You need a copyright which is then linked to a FLOSS or certain CC license
**\<msvb-mob>** Yes, the CERN Opensource Hardware (OSH) license.
**\<ArticMine>** This is a legal requirement in many jurisdictions
**\<sgp>** ArticMine msvb-mob anything else you want to discuss related to this? They should have most of the details outlines on Taiga
**\<msvb-mob>** sgp: We're done with the hardware report, thanks.
**\<sgp>** Thanks msvb-mob
**\<sgp>** 6. Open ideas time
**\<sgp>** Does anyone have anything to discuss here?
**\<ArticMine>** It seems to me this is on the right track
**\<sgp>** Ok, since it seems quiet today, we can wrap up the meeting
**\<sgp>** 7. Confirm next meeting date/time
**\<sgp>** The next community meeting will be two weeks from today on 17 February. The next Coffee Chat will be next week on 10 February: https://github.com/monero-project/meta/issues/173
**\<sgp>** 8. Conclusion
**\<sgp>** That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on /r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

317
_posts/2018-02-05-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-02-05.md Normal file
View file

@ -0,0 +1,317 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-02-05
summary: Bulletproofs, dedicated Monero conference, increasing minimum ring size, making ring size static, and miscellaneous
tags: [community, crypto, research]
author: dEBRUYNE / fluffypony
---
# Logs
**\<suraeNoether>** meeting in a few minutes
**\<sgp>** Thanks for the ping
**\<suraeNoether>** we'll be casual about it today
**\<suraeNoether>** np sgp
**\* moneromooo** adds "surae said there would be casualties today" to the minutes.
**\<suraeNoether>** floggings will continue until... the floggings continue
**\<sarang>** So, what shall we cover?
**\<sarang>** I'm writing up a technical note on our BP stuff, for addition to the MRL paper library
**\<suraeNoether>** 1: greetings, 2: your work since our last meeting, c) my work since our last meeting, and iv: what you and i just discussed i guess
**\<sarang>** it should help reviewers with notes of where we are different from the original whitepaper
**\<sarang>** ah ok, I'm getting ahead of myself
**\<suraeNoether>** hehe
**\<suraeNoether>** but i think greetings are too formal, etc
**\<suraeNoether>** you go ahead
**\<suraeNoether>** are our implementations of bulletproofs so novel that we need an MRL-XXXX ? or is this more of a monero standards-thing?
**\<sarang>** Sure
**\<sarang>** So moneromooo and I worked on getting batch verification added to BPs
**\<sarang>** which will significantly speed up initial operations for new nodes
**\<sarang>** It lets you lump together verification of multiple proofs from as many transactions as you want
**\<sarang>** Still linear time, but the scaling factor is less when you batch
**\<sarang>** I'm writing up a technical note that discusses the rationale for our switch to BPs, and talks about the math behind the changes we made from the whitepaper
**\<sarang>** These may be included in andytoshi's update to the whitepaper, but the timeline on that isn't clear
**\<sarang>** This will help out the review process by explaining what we did and why we did it
**\<sarang>** as well as beef up the MRL paper library =p
**\<sarang>** It will NOT be a full review of all the BP algorithms, which would be horrifically redundant
**\<suraeNoether>** this still makes me nervous, fwiw, because you can interpret a range proof as a ring signature with a private key from the set [0, 1, ..., 2\^N], and ruffing's theorem on verification of ring signatures implies you can't batch several of them
**\<sarang>** It's still linear
**\<sarang>** All we're doing is combining multiexp operations using linear combinations of the scalars
**\<sarang>** And keep in mind it's batching independent proofs
**\<suraeNoether>** yeah, but that's like verifying multiple signatures simultaneously
**\<sarang>** If one proof requires g\^a + h\^b = 0
**\<sarang>** \* not \+
**\<sarang>** and another requires g\^c\*h\^d = 0
**\<suraeNoether>** thing is, my reasoning is faulty for a few reasons. the first one is that just because we used borromean ring sigs to build range proofs that does not imply that all range proofs can be interpreted as ring signatures. and these range proofs are from arithmetic circuits, yeah?
**\<sarang>** You can check g\^(Aa+Cc)h\^(Bb+Dd) = 0, where the capital letters are randomly selected by the verifier
**\<suraeNoether>** ooooh
**\<suraeNoether>** hmm
**\<sarang>** Since the weights aren't deterministic, the prover can't cleverly produce proofs designed to fool this
**\<suraeNoether>** yeah and that's pretty specific to commitments, too
**\<suraeNoether>** cool, sorry for interrupting, please go on
**\<sarang>** So again, still linear, but replacing expensive curve ops with scalar ops, and only doing 1 multiexp
**\<sarang>** It's technically possible to do this for every part of the verification, but moneromooo said there could be caching issues
**\<sarang>** So we might just stick to one particular batch operation, which would be the most expensive one anyway
**\<sarang>** Also
**\<sarang>** You can do this for proofs of different aggregation levels
**\<sarang>** Now, andytoshi and benedikt have also figured out a way to allow ANY number of outputs in a single proof, and not just a power of 2
**\<sarang>** but this would require a significant overhaul and may not be worth it (they were interested for AC applications)
**\<sarang>** I say we just stick with power of 2
**\<sarang>** it'll make for easier review
**\<sarang>** This will all be discussed in the technical note
**\<suraeNoether>** well hold on though
**\<sarang>** ?
**\<suraeNoether>** i'm okay with the idea of sticking with powers of 2 but is there an efficiency reason to avoid the more general approach?
**\<suraeNoether>** is the primary reason to avoid the general # of bulletproofs because the overhaul to the code would be significant, or would it be because the gains in efficiency aren't worth it (in terms of proof size and proof verification time?)
**\<sarang>** The overhaul to the code is quite a bit
**\<sarang>** For proof size it's irrelevant
**\<sarang>** The scaling is logarithmic so it's a minor gain
**\<sarang>** But verification time is linear
**\<suraeNoether>** yeah, it always is, and always will be, but do the constants change?
**\<sarang>** If you have 9 outputs, you either pack with dummies to a 16-proof, or do an 8-proof and a 1-proof
**\<sarang>** no
**\<suraeNoether>** oh, then forget it, keep it at powers of 2 and i'm fine with that
**\<sarang>** Yeah, our numbers are small enough
**\<sarang>** andytoshi et al. were testing with giant ACs where it would matter a lot more
**\<suraeNoether>** yeah, i imagine the flexibility of the construction is important for their purposes
**\<sarang>** 16-proof is more space efficient, but 8+1 is more time efficient
**\<sarang>** slightly
**\* sarang** will stop talking now
**\<suraeNoether>** and it will also be important for our purposes later on, but for range proofs right now, we can save on fees and blockchain space and new node sync time, it's a no-brainer
**\<suraeNoether>** cool, thanks sarang
**\<sarang>** If we decide to switch later, it would change the proof structure
**\<sarang>** for what it's worth
**\<suraeNoether>** anyone else have any questions about bulletproofs and sarang's documentation of the work on bulletproofs into an MRL-XXXX?
**\<sarang>** I'm ready to be done with these!
**\<sarang>** Fun project, lots of crazy optimizations, but it's time to get this baby born
**\<suraeNoether>** For my work, I'm working on multisig, and working on incorporating some of the ideas from musig into our key merging. https://eprint.iacr.org/2018/068
**\<sarang>** Yeah, cool work discussed at BPASE
**\<suraeNoether>** there are some issues with our current key merging, although I think everything else is pretty much good to go
**\<sgp>** No more questions from me on bulletproofs
**\<sarang>** Another reason that conference was a great investment
**\<suraeNoether>** oh, and holy crap
**\<suraeNoether>** i have to thank the community
**\<sarang>** As do I
**\<suraeNoether>** for freaking sending me all over the world twice in two weeks
**\<sarang>** From the exotic shores of Switzerland to the exotic shores of... Palo Alto?
**\<suraeNoether>** this has been one of the most enlightening and fun weeks of my life, meeting such smart people with such great ideas
**\<suraeNoether>** but we'll get back to that later, I suppose
**\<sarang>** We can make many things virtual, but conferences are not currently one of them
**\<suraeNoether>** back to multisig: basically, the naive, first way anyone has ever done key merging/key aggregation is to simply sum keys
**\<suraeNoether>** so if A, B, and C want to make a multisignature wallet, they compute A+B+C as their public key
**\<suraeNoether>** this has two drawbacks. one of them is that keys can't be re-used securely, and another is that A can try to pick a key of the form A\* - B - C and get a public key A\*. this way, A can make signatures without the input of B and C
**\<sarang>** (I'll be AFK for about 10 min, sorry)
**\<dEBRUYNE>** Wasn't the latter attack discussed here a while ago too? I think luigi1111 retorted it.
**\<dEBRUYNE>** I might be conflating stuff though
**\<suraeNoether>** if so, i'm not sure where it is
**\<suraeNoether>** this goes back to the original criticisms of the ASNL ring sigs back when we first did ringct
**\<suraeNoether>** so other methods would instead of computing the simple sum A + B + C would compute a linear combination c1\*A + c2\*B + c3\*C where each c1,c2,c3 is a random challenge based on the associated key
**\<suraeNoether>** first methods tried something like c1 = H(A), but the problem became an issue where all the public keys A, B, C have to be revealed to verify a signature
**\<suraeNoether>** which brings us to another drawback of A+B+C which is that it's distinguishable from other keys: if you suspect some users have formed an N-of-N wallet and you know their public keys, it's trivial to check if a key is a multisig key
**\<suraeNoether>** the key aggregation in the musig paper computes c1 = H(A, {A,B,C}), c2 = H(B, {A,B,C}), and c3 = H(C,{A,B,C})
**\<suraeNoether>** and this one little trick (!) of the hash function makes it verifiable with only the total aggregated key
**\<suraeNoether>** long story short, it's a simple change from computing keys as a simple sum(key) to sum( H(key, list\_of\_keys)\*key)
**\<suraeNoether>** and this sounds great
**\<suraeNoether>** but then your heart falls when you find out that they use a novel and somewhat complicated proof technique with a nonstandard discrete log assumption
**\<suraeNoether>** so, i'm going through an MLSAG ring signature extremely carefully and making sure that I can substitute these keys into the proof without changing the underlying security properties of the MLSAG
**\<suraeNoether>** I don't want to make any recommendations about changes, yet, though, because of their proof technique and their strange security assumption
**\<suraeNoether>** also, fwiw, if users always roll fresh keys for their multisig wallets, we could simply insert a commit-to-keys and an opening-of-commitments set of steps in key merging, and instruct users to always roll fresh keys for each new multisig construction
**\<suraeNoether>** so there is a route for preventing this rogue key attack in both cases. i just want to take this new proof seriously
**\<suraeNoether>** any questions about multisig?
**\<luigi1111>** Yes but not now
**\<luigi1111>** I'm not really here
**\<suraeNoether>** ok we can put that on hold for now
**\<suraeNoether>** in addition to that, Sarang and I are starting to throw the first roadmap of the year together. We are taking a little bit extra time because other projects like BP and multisig are more urgent.
**\<suraeNoether>** Sarang also has a three-week cryptography course planned this summer, maybe when he gets back he can tell us about that
**\<sarang>** back
**\<sarang>** Yes
**\<suraeNoether>** good timing
**\<sgp>** Yes, sarang made this course sound pretty interesting. I'd like to hear more about it
**\<sarang>** So there was desire expressed that educational outreach is a Good Thing
**\<sarang>** And who knows, maybe eventually we can run an independent program, or team up with other projects for this
**\<sarang>** But that's time-consuming and very expensive
**\<sarang>** There's an offer this summer to do a 3-week intensive course through Duke or JHU
**\<sarang>** It costs the community nothing
**\<sarang>** and is a good opportunity to pilot a cryptocurrency-focused modern crypto course for gifted high school students
**\<sarang>** Disclaimer: I'd get paid a pittance to teach it, based on their existing pay structure, so I wouldn't request any FFS during that time
**\<suraeNoether>** pittances invested in cryptocurrencies become old toyota tacomas
**\<sarang>** Ha, it's paid in boring US currency
**\<sarang>** Any questions on it?
**\<sarang>** Course materials would be released fo free
**\<sarang>** Lectures can't be videotaped
**\<suraeNoether>** oh, i was speaking with you, Sarang, and one of fluffypony's friends about making educational youtube videos, white-board-style, that explain how bitcoin and monero work, and how ethereum smart contracts will destroy the whole ecosystem
**\<suraeNoether>** (ahem)
**\<suraeNoether>** i mean how smart ethereum smart contracts are
**\<sgp>** Course materials include slides?
**\<suraeNoether>** sarang: do you usually use slides or are you a chalk talk sort of man
**\<suraeNoether>** ?
**\<sarang>** I've moved some of it to slides for easier reuse
**\<sarang>** But not entirely
**\<sarang>** I also have a lot of it in book form now
**\<sarang>** Over 100 pages of classical and some modern material, with exercises
**\<suraeNoether>** that's pretty sweet actually. you following the footsteps of your adviser, writing your own textbook one semester at a time?
**\<sarang>** Only out of laziness
**\<sarang>** I've taught classical crypto courses before and got sick of rewriting everything
**\<suraeNoether>** the best motivator for keeping detailed notes
**\<sarang>** So anyway, comments/questions welcome
**\<sarang>** especially on the scope
**\<sarang>** This will basically be a pilot program run under the existing structure of an established program
**\<sarang>** which removes all the hassle of recruiting students, housing people, etc.
**\<suraeNoether>** neato burrito
**\<sarang>** For reference though, this doesn't mean that JHU or Duke are endorsing Monero in any way... I'd be teaching it as an unaffiliated seasonal employee
**\<sarang>** oh, sgp yes that would include slides
**\<suraeNoether>** One last time, I would like to thank the community for their amazing generosity in general, and in particular these past few weeks.
**\<sarang>** everything except for video lectures (can't release those since students are minors)
**\<sarang>** Notes also include a cool section on Enigma that includes a paper simulator you can build yourself
**\<suraeNoether>** if anyone has found any interesting papers or ideas recently, please share them! I saw that hyc spoke at a fosdem
**\<suraeNoether>** does anyone know if his talk is available anywhere?
**\<suraeNoether>** i hear he serenaded the crowd with his violin
**\<sarang>** Well I heard about this crazy new coin! It uses a DAG! And it's like a hive with fast payments and it has secure!
**\<sgp>** I would also like the link if possible
**\<suraeNoether>** is instant?
**\<sarang>** Probably!
**\<suraeNoether>** probabilistically instant?
**\<sarang>** I've turned into this huge Eeyore among local groups
**\<sarang>** They keep posting their favorite new shitcoin, and I keep telling them the whitepaper has zero crypto, protocols, or math
**\<sarang>** =p
**\<sarang>** Then they get mad
**\<sgp>** @sarang that's a great way of putting it
**\<suraeNoether>** gotta be a good red team
**\<suraeNoether>** gotta *have* a good red team
**\<sarang>** This isn't being a red team, it's being able to read
**\<suraeNoether>** okay, so there's also this idea that Sarang and I have been kicking around
**\<suraeNoether>** about hosting a Monero conference next spring in Denver, CO
**\<diego[m]>** Meeting = missed. :(
**\<suraeNoether>** eh, not really
**\<suraeNoether>** tail end anyway
**\<suraeNoether>** i've spoken with a few different possible speakers, and everyone seems to be receptive to the idea. i've costed it out, and i am astounded, btw. a conference like consensus charges huge $$ to get in, but from the numbers i'm seeing, we can break even for between 50-100 bucks a ticket
**\<suraeNoether>** if we run an FFS, it could just be free
**\<suraeNoether>** well, free except for the donors
**\<suraeNoether>** well
**\<suraeNoether>** i mean free to attendees
**\* suraeNoether** *flustered*
**\<gingeropolous>** thats because they look to profit
**\<suraeNoether>** gingeropolous: +1
**\<sarang>** It'd be funny to have a "donors" section of the program with a bunch of blacked-out names
**\<anonimal>** Venue picked out?
**\<suraeNoether>** anonimal: i have a few in mind, i ahve a spreadsheet of possibilities
**\<sarang>** He can prove it's at one of several possible venues
**\<diego[m]>** We should milk attendees for all they're worth.
**\<diego[m]>** Conference be Monero specific? Not privacy? Not open source? (Just some questions)
**\<sarang>** diego[m]: provide free milk?
**\<suraeNoether>** i want this to be a 1 or 1.5 day thing filled with technical talks. investors and venture capitalists shoudl be bored out of their minds
**\<anonimal>** In Denver or surrounding area?
**\<suraeNoether>** diego[m]: i'm open to most privacy-enhancing technology based talks
**\<suraeNoether>** anonimal: yeah, if you want i can send you a list of some places i found
**\<anonimal>** That'd be great, thanks.
**\<suraeNoether>** we can go super super cheap and go for a university if we don't want to have a cool industrial-style brewery all to ourselves
**\<anonimal>** I do miss those hills.
**\<sarang>** Orrrr we could do brewery
**\<sgp>** Have you talked with any universities? May be much cheaper and easier to host a conference there than a hotel or similar
**\<sarang>** suraeNoether: you've been talking with an event planner, yes?
**\<suraeNoether>** yep
**\<anonimal>** Any boulder connections? IIRC bigreddmachine is there.
**\<sarang>** and the zcash folkz
**\<diego[m]>** ajs and I had a similar idea a while back, so if you need any help from Monero Community, We can see what we can do. Maybe come early to decorate. :P
**\<suraeNoether>** she's organized conferences for pharma companies and doctors and stuff like that before, and she's chatting with me pro bono about it
**\<suraeNoether>** anonimal: zcashco world headquarters is in boulder. :P heh.
**\<suraeNoether>** mike from the moneromonitor podcast is out there too
**\<sarang>** I always pictured them having their headquarters in a mountain
**\<suraeNoether>** anyway, i'm glad to see such positive responses
**\<sarang>** or a lighthouse or something
**\<anonimal>** oh my
**\<suraeNoether>** i've been watching venture brothers. spiderskull island ftw
**\<sarang>** I'm telling ya, buy a Monero jet and I'll fly all the attendees there
**\<diego[m]>** Why don't we have it at a resort? :D
**\<suraeNoether>** sarang has a pilot's license, he isn't kidding.
**\<anonimal>** lol aspen
**\<sarang>** Denver is a resort... THE LAST RESORT
**\<sarang>** burn
**\<suraeNoether>** diego[m]: actually if we do summer, i was considering estes park
**\<suraeNoether>** it's a summer town in the middle of the mountains and there is a YMCA there that hosts huge huge conventions eveyr year
**\<suraeNoether>** but the cabins don't have good wifi, and i feel like that's a really really big requirement
**\<suraeNoether>** they *do* have wifi
**\<suraeNoether>** just not *great* wifi
**\<sarang>** Is it encrypted wifi? Or is it like the Stanford conference?
**\<sgp>** Gigabit ethernet #1 consideration lol
**\<anonimal>** We could do black hawk but don't get me gambling...
**\<sarang>** Which for some reason had insecure wifi that sucked ass
**\<suraeNoether>** sarang: it's far less secure than the stanford. :P
**\<suraeNoether>** anyway, i'm super happy to see this sort of response
**\<anonimal>** We could turn black hawk into the next defcon
**\<sgp>** @surae I I would go well out of my way to go to a Monero conference
**\<anonimal>** ...
**\<anonimal>** X)
**\<sarang>** We should settle on a date sooner rather than later
**\<sarang>** Or at least a couple of options so people can plan
**\<suraeNoether>** sarang: we'll try to get that hammered out before the end of the month
**\<suraeNoether>** one thing, though
**\<anonimal>** Is summer an option?
**\<suraeNoether>** i just don't want it to overlap any big known conferences, and i want to avoid late september-through-december
**\<sarang>** righto
**\<diego[m]>** Sounds fun.
**\<sarang>** We should also talk about the scope of talks, so folks from other projects have a good sense of what they'd be in for
**\<anonimal>** Let's do it after defcon.
**\<gingeropolous>** line by line presentation of the monero code
**\<diego[m]>** We're not talking for this year, though, right?
**\<sarang>** Have it scrolling in the background
**\<anonimal>** People will already be out in the U.S.
**\<sarang>** like the Matrix
**\<sarang>** Yeah not this year
**\<suraeNoether>** diego no, 2019
**\<suraeNoether>** OH MY GOD i just checked my protonmail after BPASE, i'm swamped
**\<suraeNoether>** ok, this meeting is either over or can continue without me
**\<suraeNoether>** peace out brothers\~!
**\<suraeNoether>** if anyone has any questions, please email me at suraeNoether@Protonmail.com (I'll be there for the rest of the day apparently)
**\<sgp>** I couldn't find the recording, but here's hyc's slides https://fosdem.org/2018/schedule/event/monero/attachments/audio/2585/export/events/attachments/monero/audio/2585/20180204_FOSDEM_Monero.pdf
**\<sarang>** cheers
**\<sgp>** Only one thing from me. After the chaos of bulletproofs and multisig calms down, I would like to encourage future research in the impact of ringsize and churning. Either these need more research, or we need better ways of communicating these concerns to people https://www.reddit.com/r/Monero/comments/7v601j/skepticism_sunday_february_04_2018/dtq9tnt/
**\<sarang>** I agree
**\<sgp>** Also we're discussing increasing the minimum ringsize without really knowing what the tangible benefits are
**\<sarang>** Fortunately we have good space savings we can use to our advantage
**\<sarang>** if we decide to move there
**\<suraeNoether>** sgp: I agree, and actually I've been thinking about that.
**\<dEBRUYNE>** I think the discussion doesn't pertain to whether it has tangible benefits
**\<dEBRUYNE>** It's whether it's significantly outweighs the trade-offs
**\<suraeNoether>** \^
**\<dEBRUYNE>** it significantly\*
**\<sarang>** soon STARKs will save us all
**\<dEBRUYNE>** I think an increase to 10 + making it static is worth the trade-off though
**\<sarang>** Having a tested model will be essential
**\<sarang>** Otherwise we'd just be pulling numbers out of our ass
**\<dEBRUYNE>** What should be tested?
**\<dEBRUYNE>** I mean, which variables
**\<sarang>** Well I think we need to be able to quantify what we consider the weaknesses or attack vectors, couple that with some cost function, and work from there
**\<sarang>** I don't have the answer
**\<sarang>** But I think it's the approach we should take if possible
**\<sarang>** Oh one quick addition
**\<sarang>** One of the non-OSTIF audit groups checked with their lawyers
**\<sarang>** They won't let us publish their name or statement of work in advance
**\<sarang>** I think that's far enough outside of our philosophy for this review that it takes them out of the running, unfortunately
**\<anonimal>** +1
**\<sarang>** Once we've formally turned them down, I can say who they are
**\<sarang>** Process on the other groups is moving forward, albeit delightfully slowly
**\<sarang>** More details as I get them
**\<sarang>** Although I'm not too worried, since we just added batch verification anyway, and that needs to go into the technical paper that the reviewers will get
**\<dEBRUYNE>** \<sarang> They won't let us publish their name or statement of work in advance \<= Can you elaborate on this?
**\<sarang>** So, I told all the prospective groups that we want to publicly discuss all SoWs and prices prior to funding, so we can make an informed decision
**\<sarang>** As well as share the results of the audit(s)
**\<sarang>** SoWs being important since they explicitly outline the scope of the review
**\<sarang>** https://www.irccloud.com/pastebin/RAEbSR24/
**\<sarang>** This is the email from their rep
**\<sgp>** @dEBRUYNE I totally agree that we should weigh the benefits and cons. We just need more justification than "10 is a larger number than 5"
**\<dEBRUYNE>** sarang: I see. Was this group favored qualitively? If so, perhaps we can think about a work around.
**\<sarang>** They're a well-established group
**\<sarang>** I have no doubt that they would do a thorough and correct review
**\<dEBRUYNE>** Ok. Let me put some thoughts into this
**\<sarang>** But I don't like the idea that I'm the only one (or part of a non-public group) that decides this
**\<sarang>** Once I get final word from all OSTIF prospects, we'll have a better idea of any differences in scope
**\<sarang>** What they care about more than absolute price estimates is their rates
**\<sarang>** FWIW
**\<suraeNoether>** on a slightly different note, all the slides and videos of the talks at BPASE this year are online here: https://cyber.stanford.edu/bpase18 \<--- I highly recommend @roasbeef's talk, but slow it down to 50% speed
**\<sarang>** lol
**\<sarang>** it's true
**\<sarang>** He would make a fantastic auctioneer
**\<anonimal>** What you're asking for is completely within the realm of open source principles. How can they call themselves OSTIF.
**\<sarang>** anonimal: the group I linked was not an OSTIF group
**\<sarang>** It was a group recommended by fp
**\<anonimal>** Oh, "non-OSTIF", I see now, thanks.

281
_posts/2018-02-11-logs-for-the-dev-meeting-held-on-2018-02-11.md Normal file
View file

@ -0,0 +1,281 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2018-01-28
summary: Discussion of open PRs and issues, Bulletproofs and auditing, March HF, slight PoW tweak, dedicated Monero hardware wallet, and miscellaneous
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
# Logs
**\<rehrar>** ArticMine luigi1111 luigi1111w fluffypony smooth hyc moneromooo anonimal vtnerd pigeons endogenic ErCiccione
**\<vtnerd>** present
**\<ArticMine>** Hi
**\<msvb-mob>** Hello.
**\<ErCiccione>** hi folks
**\<vtnerd>** jtgrassie
**\<sgp>** Hi
**\<rehrar>** Agenda: https://github.com/monero-project/meta/issues/174
**\<rehrar>** Jaquee medusa dsc
**\<rehrar>** kenshi84 MoroccanMalinois anyone else?
**\<MoroccanMalinois>** hi
**\<rehrar>** We've already kind of start on 1. Greetings
**\<rehrar>** If you're still hanging out in the peanut gallery, throw a hello on by to us.
**\<rehrar>** Heck, if you don't plan on participating, but just want to watch, we'd still appreciate a hello. :)
**\<Vespco>** Hello
**\<endogenic>** hello
**\<endogenic>** this is dog
**\<rehrar>** As you guys probably see, it's not 17 UTC. We're trying out an hour earlier by request of last meeting. We can decide today whether it was a good idea or not.
**\<pigeons>** hi
**\<rehrar>** suraeNoether sarang
**\<rehrar>** 2. Brief review of what's been completed since the previous meeting
**\<rehrar>** Anyone have anything to report?
**\<moneromooo>** DB crash fix. Misc minor fixes found by coverity. Pool max size. Fluffy blocks on by default. I think that's the main ones.
**\<moneromooo>** And I just PR'd my "store prunable and unprunable data separately" patch.
**\<moneromooo>** Oh, and the --testnet-xxx options are gone now. No more duplication.
**\<moneromooo>** None of that is merged yet, but nothing got merged in two weeks I think.
**\<rehrar>** Thanks moneromooo! You are a shining star. Take a bow.
**\<rehrar>** Anyone else have anything to report? If not we can move on.
**\<moneromooo>** Not all by me.
**\<vtnerd>** I guess I will report for jtgrassie, who looked at the echo off permanently issue with the wallet
**\<rehrar>** a bow for your presentation ;)
**\<vtnerd>** he has a fix that is similar to moneromooo 's patch, but does trigger immediate shutdown on ctrl-c still
**\<luigi1111>** Does that need a resync?
**\<vtnerd>** there are still underlying issues in the signal handler, and if I can't figure out a way to unbreak that code easily we may have to go with the somewhat-hack approach until that gets worked out
**\<iDunk>** luigi1111: It will convert the db from v1 to v2, AFAIU.
**\<moneromooo>** no resync
**\<luigi1111>** Perfect
**\<vtnerd>** and I'm still interested in wallet scanning perf (as usual), and figure out how to do atomic swapping ... if anyone has thoughts on the latter let me know privately for now
**\<vtnerd>** or what this is the whats been completed section, whoops
**\<endogenic>** i have a question for later rehrar
**\<rehrar>** ok
**\<rehrar>** Alright, we ready to push forward?
**\<sarang>** Hullo, sorry for delay, was filing taxes :/
**\<rehrar>** Any dev stuff to report for the last two weeks?
**\<rehrar>** sarang \^
**\<sarang>** It's just about the most fun you can have while still wearing pants
**\<sarang>** Yes, a few quick thing
**\<sarang>** The BP paper was massively updated to reflect a lot of the optimizations we've been including
**\<sarang>** I'm running final checks against that paper (and made a few corrections to the updated paper that have been sent to the authors)
**\<moneromooo>** Oh good point, I forgot about more BP stuff ^\_^
**\<sarang>** I had also worked up a BP technical note, but the paper update makes that obsolete
**\<endogenic>** mooo same
**\<sarang>** However, I think we've made all the optimizations that we want
**\<sarang>** On the audit front, OSTIF groups are slow to provide SoW but apparently that's happening early this week
**\<sarang>** Benedikt Buenz (BP author) wants to review as well
**\<sarang>** Thoughts on how much to offer Benedikt?
**\<sarang>** Having both him and an audit group review will be good: he'll confirm our math, and the audit group will check our final code for holes
**\<rehrar>** Make him an offer he can't refuse
**\<sarang>** lol
**\<sgp>** I don't really know what the right amount is
**\<endogenic>** no pony heads though pls
**\<sarang>** I'm thinking a rate of 800 USD per day would be competitive if it only takes him \~5 days or so
**\<sarang>** He's the most qualified person to do this
**\<endogenic>** then that's cheap
**\<endogenic>** we're lucky
**\<ErCiccione>** that's less than i expected
**\<sarang>** Yeah, I'd go higher if no objections
**\<sarang>** I asked what his rate is, and am waiting to hear back
**\<ArticMine>** It is on the low end
**\<endogenic>** well ErCiccione do keep in mind we benefit from addtl reviewers
**\<endogenic>** so frugality is useful there
**\<rehrar>** 20 XMR bam
**\<sarang>** So I'll do a combined FFS once we've confirmed the OSTIF rate and Benedikt's rate
**\<endogenic>** thanks sarang :)
**\<sarang>** Separarely, I've been working with suraeNoether on some multisig developments from BPASE
**\<sarang>** curriculum development for 3-week summer course
**\<sarang>** Will be speaking at a Portland crypto conference about privacy (funded by the organizers, no FFS needed)
**\<sarang>** and the paper on PHANTOM (related to SPECTRE) just came out, so I'm on top of that
**\* sarang** is done talking now
**\<rehrar>** woohoo, sounds awesome
**\<sarang>** questions welcome
**\<endogenic>** awesome
**\<sarang>** read the new BP paper if it interests you
**\<rehrar>** alright let's jump into the big one: 3. March hardfork items + code freeze
**\<rehrar>** So... code freeze has been "close" for a couple months now
**\<rehrar>** when is it? :P
**\<moneromooo>** When we pushed all we need,
**\<moneromooo>** We need pony back, so we can't discuss this if we don't know that.
**\<moneromooo>** One thing we need to discuss before we do though:
**\<moneromooo>** We discussed changing PoW slightly, and periodically, in order to further our goal of decentralization - to deter ASIC creation some more.
**\<moneromooo>** So we're planning to change PoW before the fork, if the community agrees.
**\<rehrar>** before March?
**\<moneromooo>** Yes. We're still planning on a march fork.
**\<pigeons>** i would expect changing the PoW before this fork to be at least slightly controversial
**\<rehrar>** This seems a bit sudden and soon
**\<moneromooo>** Emphasis on *slightly* btw. It's still mostly Cryptonight.
**\<rehrar>** ah, makes more sense
**\<sgp>** I would like to hear a lot more about the changes and what they mean
**\<rehrar>** \^
**\<rehrar>** can you explain moneromooo?
**\<endogenic>** what deters ASICs?
**\<ErCiccione>** sgp: +1
**\<iDunk>** Is this about the parameters tweaks othe suggested ?
**\<pigeons>** endogenic: having the work and investment they put in invalidated
**\<moneromooo>** Just a few more simple ops in the inner loop. They mean... different hashes.
**\<endogenic>** pigeons: how to detect their work?
**\<ArticMine>** It keeps ASIC developers off balance
**\<endogenic>** or what is it :p
**\<moneromooo>** endogenic: it doesn't need to. I have patches for most miners ready.
**\<moneromooo>** Those (software) miners just update. Any ASIC can't.
**\<endogenic>** even if it's modular?
**\<moneromooo>** What is a modular ASIC ?
**\<endogenic>** it -> asic
**\<msvb-mob>** pigeons moneromooo: We in the hardware team are onboard with PoW changes but cannot recall all hardware wallets worldwide to swap chips.
**\<endogenic>** modular hardware
**\<moneromooo>** You have hardware mining ?
**\<pigeons>** msvb-mob: I wouldn't expect hardware wallets to need to mine or validate PoW
**\<msvb-mob>** Not to make the debate a can of worms, but if anybody has a strategy idea for us hardware folks, let's please consider the probloem offline.
**\<pigeons>** just sign i would think
**\<rehrar>** msvb-mob, why does a hardware wallet need to do anything with PoW?
**\<msvb-mob>** pigeons: Okay, but changing the Cryptonote PoW wouldn't that mean changing transaction operations as well?
**\<moneromooo>** No.
**\<pigeons>** transactions don't use PoW
**\<pigeons>** bundling them in blocks do
**\<msvb-mob>** pigeons rehrar moneromooo: Okay, that's the answer I wanted to hear, thanks.
**\<rehrar>** you sign the tx and broadcast them to the network, then the miners (separate entities) mine and put them in blocks
**\<rehrar>** so you're good, unaffected :)
**\<rehrar>** well then, it seems we don't have a lot to discuss on point 3 without the horsey
**\<rehrar>** seeing as how Core Team has more or less delegated to him to handle releases and stuff
**\<rehrar>** though I hope he may show up soon, as....it's getting close to March
**\<rehrar>** Any final thoughts on 3?
**\<endogenic>** we could just ask him lol
**\<endogenic>** that usually works
**\<moneromooo>** I did. It didn't.
**\<endogenic>** "we" :p
**\<luigi1111>** He should be home by now
**\<moneromooo>** Might still think 5 GMT though.
**\<endogenic>** fluffypony:
**\<rehrar>** I let him know yesterday about the time change
**\<moneromooo>** Did he reply ? He's been mostly AFK for days.
**\<rehrar>** and he responded. Got the message.
**\<rehrar>** "ok cool"
**\<rehrar>** we can break that down and analyze that sentence if we want
**\<rehrar>** Alright, maybe he'll show up and we can come back to this
**\<rehrar>** meantime, let's move on to 4. Code + ticket discussion / Q & A
**\<endogenic>** ooh me me
**\<rehrar>** go endogenic
**\<endogenic>** no sorry my mistake
**\<endogenic>** ticket discussion first?
**\<endogenic>** i would step on that otherwise
**\<rehrar>** yeah, if you don't mind. Next is 'any other meeting items'
**\<rehrar>** and you can go crazy there :)
**\<endogenic>** well i thought it was q&a but yeah
**\<rehrar>** ah, I see. I thought it was unrelated.
**\<rehrar>** *shrug* for lack of other people piping up with discussion, go ahead
**\<endogenic>** hah ok
**\<endogenic>** so i want to beef up our code review capabilities
**\<endogenic>** the reason is that i found some code got merged without it really having been verified
**\<endogenic>** which in some cases is necessary
**\<endogenic>** i mean it's not in everyone's interest to verify every single special case code branch
**\<endogenic>** except
**\<endogenic>** when it becomes a problem for the codebase
**\<endogenic>** problem is
**\<endogenic>** we cant just say "who is the best reviewer... vtnerd... you are now responsible for reviewing all code"
**\<endogenic>** first no one man can take responsibility for that
**\<endogenic>** for everyone
**\<endogenic>** second what if something happens .. bus effect etc
**\<endogenic>** so i wanted to ask. can we figure out a system for this? like sarang's work but we must understand imho he has to be involved to vet the vetter
**\<endogenic>** or it would be the blind leading the blind
**\<endogenic>** in a manner of speaking
**\<moneromooo>** You just need people to review, don't you. So review, or find people to review.
**\<endogenic>** no
**\<moneromooo>** To the first part ?
**\<rehrar>** It's tough on an open source project. People do many stuff in their free time and aren't getting paid. Perhaps it would be beneficial to get an FFS proposal by some volunteer coders (two or three) to review all PRs?
**\<endogenic>** basically. but to both... it is not able to be the solution
**\<ErCiccione>** i think the problem here is the same the GUI has. We need more people...
**\<endogenic>** we have people
**\<endogenic>** they exist
**\<endogenic>** do they have the incentives?
**\<rehrar>** this is true
**\<endogenic>** rehrar sort of in that direction
**\<endogenic>** but there needs to be a mediator who is technically qualified imo
**\<endogenic>** and there are other problems
**\<endogenic>** vtnerd just pinged me privately with one
**\<endogenic>** imo we have to sort of standardize the effort
**\<endogenic>** working group?
**\<endogenic>** that's one part
**\<vtnerd>** whoa, standardize? not something I would make claims to. I've never seen an effective way to do that
**\<endogenic>** that's not what i mean
**\<rehrar>** what we also need to realize and people and incentives, is that throwing money at people doesn't always make them want to do something
**\<rehrar>** If they work full time, they may not want to come home and be obligated to continue working (as opposed to contributing when they want)
**\<endogenic>** we ourselves already have the right incentives
**\<endogenic>** but disinterested parties may just gloss over lines of code
**\<endogenic>** which look innocent
**\<endogenic>** when i say standardize i mean we should take the fact that such problems exist and make them visible to the community
**\<vtnerd>** ahh ok, interesting.
**\<rehrar>** Well, there is a Skepticism Sunday going on right now
**\<endogenic>** no
**\<endogenic>** we want a working group with a document of problems that happen such as what i mentioned above
**\<rehrar>** Ah, I see.
**\<rehrar>** Would you be willing to head this group then?
**\<endogenic>** i cant rn
**\<rehrar>** Well, you and I can talk later after the meeting, and I'll see what I can do.
**\<endogenic>** vtnerd might be
**\<endogenic>** he is an expert
**\<rehrar>** I'll be down to give whatever help I can to whoever heads up this group.
**\<endogenic>** and he\*
**\<endogenic>** i appreciate that :)
**\<rehrar>** I think everyone agrees that more thorough review of the code can only be a good thing, it's just a matter of people, time, and actually getting it done
**\<rehrar>** Alright, msvb-mob wanted some time for a few hardware things if that's ok with everyone.
**\<msvb-mob>** Yes please, but just short.
**\<rehrar>** floor is yours
**\<msvb-mob>** I'll be advertising planning work for the Las Vegas events of August once in a while, anyone interested can look at:
**\<msvb-mob>** https://taiga.getmonero.org/project/michael-vegas-august-2018
**\<msvb-mob>** m2049r[m] made a more or less incredible contribution to the greater Monero community by a first release (today) of a Monerujo-hw firmware.
**\<msvb-mob>** https://github.com/m2049r/monerujo-hw/
**\<rehrar>** woohoo!
**\<msvb-mob>** We want to do the most we can with the firmware (on our own self grown hardware) and a few questions are arising about how far we can take a testnet approach to new users.
**\<msvb-mob>** New hardware users, that is. Since we can't recommend using the wallet for real funds.
**\<msvb-mob>** So if it would be okay to recommend trading testnet funds for a free t-shirt at events, for example.
**\<msvb-mob>** The last question on my agenda, is if anybody knows of the chance to insert a hardware wallet request to the group making videos (Savandra.)
**\<msvb-mob>** That's all for me.
**\<msvb-mob>** fluffypony focused discussion on a vulnerability mitigation group last meeting, is that a topic we want to follow up on?
**\<ArticMine>** Yes
**\<msvb-mob>** ArticMine: Yes to which question?
**\<ArticMine>** To the vulnerability mitigation group
**\<rehrar>** As far as I know, savandra's last video is focusing on the community and that ends his FFS. We can ask him if he'd be willing to do another FFS to make another video for Hardware.
**\<rehrar>** alright, any last minute meeting items?
**\<rehrar>** alright, next meeting time
**\<moneromooo>** No talk about the vulnerability mitigation group ?
**\<rehrar>** oh, sorry. I may have misread all that
**\<rehrar>** I thought it was a simple question/answer
**\<rehrar>** To follow up on that topic, the Vulnerabliity Mitigation Group is headed by sgp and is on mattermost
**\<moneromooo>** What does this do ?
**\<rehrar>** sgp, you around?
**\<moneromooo>** Try to devise workarounds till a fix is in, etc ?
**\<sgp>** Yeah, but are you sure this is the same? Ours is the "malware response workgroup"
**\<rehrar>** I think....this is the same, yes.
**\<rehrar>** But....maybe not? :P
**\<ArticMine>** It is a different issue
**\<rehrar>** then disregard me completely
**\<rehrar>** who is qualified to speak on that?
**\<msvb-mob>** sgp: The 'malware response workgroup' is what I meant when contorting the words above.
**\<sgp>** The scope of "my" workgroup is to help those whose computers have been exploited for mining or ransomware
**\<msvb-mob>** sgp: Sounds like most primary things about the workgroup have been decided then, good work.
**\<endogenic>** sgp: i've been curious about the personal network security consequences of operating a monero node too. would be nice to talk with you about that sometime
**\<rehrar>** Alright. We're over the designated time. So let's confirm next day:
**\<rehrar>** February 25th. Did this new time work for people?
**\<rehrar>** we were short dEBRUYNE and gingeropolous today. :'(
**\<rehrar>** but it may be for other reasons
**\<rehrar>** We can keep 16 UTC for next meeting unless there are great objections.
**\<rehrar>** If not, meeting over. :) Thanks everyone for coming.
**\<ArticMine>** I would suggest also keeping it through the time changes
**\<msvb-mob>** rehrar: Most excellent moderation, thank you.
**\<sgp>** Not really meeting-worthy, but I would like to add the Monero Coffee Chats to the getmonero website
**\<msvb-mob>** rehrar: If possible, would you please fork and pull request your source logos to the /documents/graphics/logo/ directory?
**\<msvb-mob>** rehrar: Logo sources, as long as their formats are Opensource we don't need bitmaps.
**\<rehrar>** Ok, I'll get to that as soon as I can
**\<sgp>** Are people against me uploading compressed versions of the coffee chats to the site? Or are people concerned they will be too large
**\<rehrar>** an hour is kind of long and would make having a fork on your local machine a big pain
**\<rehrar>** especially as there will be more and more of them
**\<rehrar>** Perhaps links would be better?
**\<msvb-mob>** sgp: Same consideration we have with large promotional photos of PCBs, which don't belong in revision control for obvious reasons.
**\<vtnerd>** articmine : canada does that crap too (arbitary timezone changes)?
**\<vtnerd>** ahh they do too, I hate timezones altogether actually, as stated previously
**\<sgp>** @rehrar does the website allow me to embed YouTube videos, or would I have to do a simple link?
**\<ArticMine>** Different countries do it at different times in the year . Even within a country there a all sorts of differences
**\<ArticMine>** So for something where there are people all over the world it is best to stick with one time at UTC
**\<rehrar>** I don't see why not an embedded video
**\<rehrar>** except that people with javascript shut down won't be able to see it
**\<rehrar>** I think we should keep the website free from the necessity to turn on Javascript for anything, so I would advocate for a link, but that's just me.

226
_posts/2018-02-12-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-02-12.md Normal file
View file

@ -0,0 +1,226 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-02-12
summary: Bulletproofs, auditing Bulletproofs, dedicated Monero conference, and miscellaneous
tags: [community, crypto, research]
author: dEBRUYNE / fluffypony
---
# Logs
**\<suraeNoether>** Allrighty everybody
**\<sarang>** Gather 'round, everyone; it's almost time
**\<suraeNoether>** Welcome welcome
**\<ErCiccione>** hi research lab folks!
**\<MoroccanMalinois>** hi
**\<suraeNoether>** So we don't really have an agenda. I want to sort of go around the circle and see what folks have been working on. Sarang and I blabbed a lot last week, so we can go last.
**\<sarang>** Someone! Anyone!
**\<serhack>** Hello!
**\<ArticMine>** hi
**\<sarang>** Orrrrr one of us can go if nobody volunteers?
**\<ArticMine>** Please
**\<gingeropolous>** i discovered "R shiny", a package that'll let me turn my R sims into little webpages so ppl can fiddle with them. Still working on wrapping it into my "code"
**\<sarang>** Oh nice
**\<suraeNoether>** oh actually
**\<suraeNoether>** gingeropolous we should talk about that
**\<suraeNoether>** because I have these simulations of a cryptocurrency network, blocks being propagated, each node tracks its own local blockchain and computes difficulty, modulating its own local block arrival rate
**\<suraeNoether>** i built it so that i can test consensus rules like spectre or phantom or nakamoto, or difficulty computations, stuff like that
**\<gingeropolous>** cool.
**\<suraeNoether>** it'd be fantastic for that to fit into a webpage with animations
**\<gingeropolous>** there have been a couple of cryptocurrency network simulators over the years... did u roll your own?
**\<suraeNoether>** does your package take R code and execute it in the browser clientside? or does it take a transcript of a simulation from R and animates it?
**\<suraeNoether>** yeah, i rolled my own
**\<suraeNoether>** a lot of the simulators out there don't do what i want them to do, or do way too much
**\<gingeropolous>** i honestly don't know if it'll do what I want yet. Generally, there's a web page where a user can plug in parameters and hit "go". Then the R script runs on the server, and when done, delivers the results
**\<gingeropolous>** so it may not do a live animation, where u can tweak params on the fly
**\<suraeNoether>** aaaah interesting, mine doesn't either, but you can program the parameters to change dynamically
**\<gingeropolous>** but you could set timeframes and get output for a given timeframe
**\<suraeNoether>** that's fantastic, we should talk more about that later
**\<gingeropolous>** cool. i'll let u know when i get my dyn blocksize one wrapped
**\* suraeNoether** thumbs up
**\<suraeNoether>** cool, sarang, want to bring us up to speed on how your last week unrolled?
**\<sarang>** Sure, plenty to discuss
**\<sarang>** First up, BPs
**\<sarang>** Updated paper was released that talks optimizations
**\<sarang>** We've implemented them already (the ones we intended to, at least)
**\<sarang>** I had worked up a BP tech note discussing how we differed from the original paper, but the new paper makes that obsolete
**\<sarang>** I checked the new paper against our code and we're golden
**\<sarang>** This will help the audit
**\<sarang>** For the audit, Benedikt Buenz is interested and will be available soon
**\<sarang>** Waiting on OSTIF SoWs from this week... other groups were less willing to share data publicly, which I do not like
**\<sarang>** I'll put up an FFS to fund Benedikt and a pro group, with overruns going toward conferences or to general fund
**\<sarang>** I'll be speaking at an intro cryptocurrency conference in Portland next month; funded by the organizers, so no FFS needed
**\<sarang>** Either suraeNoether or I will likely speak at a large TEDx youth event in April
**\<sarang>** PHANTOM paper (cousin to SPECTRE) was released and is under review
**\<sarang>** Finally, summer course...
**\<sarang>** there's an option for a single 3-week course or two 3-week courses. It'd be a full-time role, so I'm weighing the options for which to accept
**\<sarang>** Opinions/comments/questions welcome for all of these things
**\* sarang** drops the microphone
**\<suraeNoether>** wow. any questions?
**\<ErCiccione>** a ton of good news :)
**\<sarang>** Soooooo how long should I be away this summer =p
**\<sarang>** It's a lot of work to teach these intensive courses, but I've had a lot of students go on to do math/CS because of their summer course participation, so it works
**\<serhack>** whoa, a lot of activities! amazing!
**\<sarang>** Yeah, a busy month!
**\<suraeNoether>** It'll probably be a nice 3-week break from directly working on bulletproofs, you'll enjoy having that intellectual shift in gears
**\<ArticMine>** One the optimizations what is the good news bottom line on tx size and verification time? Since this affects fees blocksize etc
**\<sarang>** So txn size is unchanged from the initial multi-output stuff we worked on
**\<sarang>** For verification time I'll have to check the benchmarks... there are basically two classes of speedups there
**\<sarang>** One is for established nodes... they'll use the multiexp operations we've introduced, which lead to much faster verification than the Borromeans
**\<sarang>** The second is for new nodes... they can batch verify as many txns as they want very quickly
**\<moneromooo>** It's set up to batch per block fwiw, so current nodes also benefit.
**\<sarang>** Sure, but I assume much less
**\<sarang>** I've considered the batch verification to really be for the new nodes, since they have a lot to work on
**\<moneromooo>** Well, it's not set up to batch across blocks :)
**\<sarang>** Did not know that!
**\<suraeNoether>** on another note, someone brought up the question: why do our range proofs cover such a large size? which made me think of some of my own questions: isn't verification time for a range proof linear in the size of the set? And if so, would it really be 2\^-32 times faster to validate a range proof on [0, ..., 2\^32] than [0, ..., 2\^64]? i realized i have some gaps in my range proof knowledge
**\<sarang>** Fortunately that's not a consensus thing, so a client could do that later
**\<sarang>** moneromooo: why not batch across blocks for new nodes?
**\<moneromooo>** More complicated.
**\<sarang>** Ha, fair answer
**\<moneromooo>** Besides, range proofs are only checked since last end of known hash data.
**\<hyc>** (Hi all. just dropped in. Just finished giving a Monero lecture here at Ulster University in Belfast. So far doesn't look like I hooked any aspiring graduates...)
**\<sarang>** hyc: still worth it!
**\<suraeNoether>** hyc so i take it the fiddle is only *mythically* hypnotic, not literally, then?
**\<suraeNoether>** so what's with the range proof set size? sarang? thoughts?
**\<sarang>** So ArticMine the optimizations are for the verifier time, not for txn size in this case
**\<sarang>** Well the only requirement is that the # of bits be a power of 2
**\<hyc>** lol. I screwed up, played at end of talk instead of beginning ;)
**\<sarang>** txn size is basically unaffected by this
**\<sarang>** So it comes down to the increase in verifier time
**\<sarang>** and the complexity of making the range size be height-dependent
**\<ArticMine>** and verification still scales linearly with number of outputs so no real changes on fees ,, block weight / size etc
**\<sarang>** Right, just with faster constants
**\<ErCiccione>** uuh belfast, tiocfaidh ár lá hyc!
**\<suraeNoether>** ok, so anyway
**\<suraeNoether>** :)
**\<sarang>** So
**\<sarang>** Questions on the audit?
**\<sarang>** Or speaking engagements?
**\<sarang>** Or summer teaching?
**\<sarang>** 3 weeks vs 6 weeks?
**\<moneromooo>** I'd like to know when's the deadline to have a cleaned up patchset for BPs for the review. I've been busy elsewhere and kinda left it lying as is for the last... week or two.
**\<moneromooo>** I lose track of time.
**\<suraeNoether>** i haven't the foggiest idea, you're the person i would have asked. :P
**\<sarang>** Well
**\<suraeNoether>** oh actually
**\<suraeNoether>** you meant for the code review
**\<sarang>** Benedikt will be reviewing the Java code, so no worries there
**\<sarang>** I want to have the other audit started within a month
**\<moneromooo>** Yes. When do I need to have it ready and cleaned up :)
**\<moneromooo>** OK.
**\<sarang>** There's no real deadline; they'll start when we're ready
**\<sarang>** But the OSTIF groups are being slow on SoW
**\<sarang>** I've been told this week
**\<sarang>** and then time to review, raise funds, and give them the go-ahead
**\<sarang>** hence the month
**\<hyc>** wait, auditing the java code? so we still need someone to verify that the C++ impl matches the java
**\<sarang>** The only other change to be ported from Java since the last code I sent is just the code comments referencing paper lines, which are changed now
**\<sarang>** hyc yes
**\<sarang>** We're doing both
**\<suraeNoether>** benedikt is doing the java, i believe OSTIF was going to do the C++
**\<sarang>** Benedikt will verify that the Java matches the math
**\<sarang>** since he did the math
**\<hyc>** ok
**\<sarang>** OSTIF group will do the C++ to the Java
**\<sarang>** and the paper, to the extent they can
**\<sarang>** I wanted overlap
**\<suraeNoether>** there is some fault-tolerance value in checking two implementations instead of one
**\<sarang>** Well, and Benedikt knows the math better than anybody, and had already done a separate more general Java working
**\<suraeNoether>** Anyway, at my end of MRL, my work this past week was largely focused on multisig and musig. I expressed concern last week that our current multisig scheme is vulnerable to key cancellation. since then, luigi1111 has proven me wrong, which is fantastic: when we compute keys, we use an authentication procedure that ensures that a key-cancelling adversary can't both cancel keys and pass authentication
**\<suraeNoether>** without violating the discrete log assumption.
**\<suraeNoether>** but i'm still looking into musig's manner of computing keys, which is a way of computing aggregate keys without an authentication procedure in one step, which is nice, but not necessary
**\<suraeNoether>** for our purposes
**\<suraeNoether>** in addition to that, I've been communicating with Tim Ruffing and his colleague Russel Lai about an upcoming paper on their sublinear ring signatures that re-uses group elements and integers to reduce signature space and verification time, which is neat
**\<suraeNoether>** more generally for sublinear ring signatures, though, I've been sort of casually looking into how one would implement a ring signature with an arithmetic circuit. so we can exploit the goodness of bulletproofs for our signatures also
**\<sarang>** Yeah, revisiting that with the addition of some group operation optimizations will be intriguing
**\<suraeNoether>** yeah, actually that brings up the following point
**\<suraeNoether>** all the multi-exp optimizations that we have been enjoying with bulletproofs will make RTRS RingCT much faster as it is
**\<suraeNoether>** we may need to do some benchmarking. no matter what, this sublinear ring signature idea seems to not want to die. :)
**\<hyc>** yay, nice. and I suspected bulletproofs would do more for us, that's very interesting
**\<sarang>** BPs have a lot of potential
**\<suraeNoether>** knowing blockstream, they'll beat us to it, but hey
**\<sarang>** Blockstream is working on the AC stuff quite heavily
**\<sarang>** but their work is on a different curve and a different codebase
**\<sarang>** a beautiful synergy
**\<sarang>** plenty of upward mobility
**\<sarang>** other business lingo like that
**\<sarang>** Any other topics of interest?
**\<sarang>** I think I've covered the major ones for m
**\<sarang>** \*me
**\<suraeNoether>** I already mentioned my cryptocurrency network simulation, which is a sort of sandbox to test things like SPECTRE and PHANTOM and variations in difficulty computations, and to test things like how network topology influence security of various proposals under various attack scenarios
**\<suraeNoether>** which if anyone is interested, is here: https://github.com/b-g-goodell/research-lab/tree/master/source-code/Poisson-Graphs
**\<sarang>** Poison graphs, eh?
**\<sarang>** deadly
**\<suraeNoether>** currently produces a transcript of events as the network evolves. the code needs better commetns and more detailed reports, and there is one known bug, but
**\<suraeNoether>** and i took an issue out already with that bug
**\<suraeNoether>** In addition to all that and the educational outreach Sarang mentioned, I've also been looking into the first monero conference idea more deeply
**\<sarang>** I love the idea
**\<gingeropolous>** any thoughts on difficulty algo?
**\<ArticMine>** Excellent idea
**\<sarang>** gingeropolous: let's chat about the state of that
**\<suraeNoether>** I am scoping out a handful of locations this week. Most of the venues I've looked at cost between 7500 USD and 10k USD for two days. Catering would cost around 3k for two days, AV equipment will be at most a 3-4k, which is probably an over-estimate
**\<suraeNoether>** if we provide travel support to, say, 9 speakers, and take them all out to dinner, that's an additional 4k or so
**\<suraeNoether>** in total, not including web presence and advertising and printing up programs and stuff, we're looking at under 25k for the entire event
**\<sarang>** How does that compare to the earlier estimates you had?
**\<suraeNoether>** cheaper by a few thousand
**\<sarang>** Nice
**\<sarang>** Will you charge for tickets?
**\<sarang>** to offset?
**\<ArticMine>** What locations are you considering?
**\<suraeNoether>** ArticMine: All the locations I'm looking into are in the Denver area
**\<scoobybejesus>** How many potential attendees?
**\<gingeropolous>** the right place for paranoia
**\<suraeNoether>** initial numbers were 75-100, but i'm terrified of mis-estimating that
**\<suraeNoether>** if this were a pharmaceutical conference, to get 100 attendees, you need to send out 3000 invitations or more
**\<suraeNoether>** any cost above what I just quoted would be marketing costs
**\<sarang>** I expect a lot of people will want to go, but travel will be their deciding factor
**\<hyc>** lol. Who is the target audience, devs, general user community?
**\<suraeNoether>** and I would prefer this to be a small technical sort of thing rather than a big flashy Dash-funded concert
**\<suraeNoether>** i want folks to present technical talks on privacy-enhancing technologies in cryptocurrencies
**\<sarang>** That part sounds like a lot of overlap with the Redacted conference that the Portland group is planning
**\<gingeropolous>** can i pump my ico?
**\<suraeNoether>** gingeropolous: I love Ice Cream Offerings, brother, you are more than welcome
**\<gingeropolous>** please dedicate many thousands to ice cream catering
**\<sarang>** Actually nvm suraeNoether, they've tooled their conference to be general/business privacy
**\<ArticMine>** The question of protocol scaling in Monero vs virtually an other coin is significant
**\<ArticMine>** any other
**\<suraeNoether>** ArticMine: agreed, and we face some very unique challenges specific to our protocol
**\<ArticMine>** and some significant advantages
**\<suraeNoether>** So after I take a look at actual venues, I'll have it narrowed down to a few specific locations.
**\<suraeNoether>** Does anyone have any questions for either me or Sarang, or did anyone hop in late and want to describe a project they've been working on?
**\<sarang>** What's the event name?
**\<suraeNoether>** i'm sure someone will come up with a good acronym
**\<oneiric>** what is rough estimate for a date?
**\<suraeNoether>** Summer 2019
**\<sarang>** Kunvenante
**\<sarang>** "gathering"
**\<gingeropolous>** so... i think this conference is great... is there any chance we could get an event planner to do this? U two are way too overqualified and valuable, timewise....
**\<gingeropolous>** unless this is a nice mental bikeride
**\<suraeNoether>** I've been speaking with an event planner pro-bono actually
**\<shillobear>** will carlos matos be a guest speaker?
**\<suraeNoether>** all the numbers I gave you are from an e-mail form her
**\<hyc>** nice
**\<sarang>** gingeropolous: I absolutely do not want to plan a conference 0\_0
**\<suraeNoether>** sarang \^
**\<gingeropolous>** noice
**\<suraeNoether>** and if we decide to go forward with it (it seems like everyone is okay with that) we'll contract out with her directly once things are a little more finalized
**\<hyc>** sounds like a great idea.
**\<hyc>** on that note I gotta bug out. ttyl
**\<sarang>** Yeah we're just about at 18:00 now
**\<sarang>** Last remarks?
**\<suraeNoether>** good night and good luck!
**\<suraeNoether>** or good morning!
**\<oneiric>** sorry if dumb question, is the revised bulletproofs paper up somewhere?
**\<sgp>** Sorry for missing the meeting. I read the logs and everything looks good to me :)
**\<sarang>** oneiric: https://eprint.iacr.org/2017/1066.pdf
**\<oneiric>** thanks sarang :)
**\<sarang>** np
**\<suraeNoether>** Kongreso Monero 2019
**\<suraeNoether>** Monero Kongreso? :P
**\<gingeropolous>** Kongrenero
**\<gingeropolous>** portmanteau all the things
**\<gingeropolous>** and then we can have an intro video to the tune of "Canyanero"
**\<sarang>** excellent reference
**\<suraeNoether>** Kongreso Monero Barolo?
**\<gingeropolous>** i;ll work on organizing an overnight hackathon dj'd by boris brejcha, 10 PM to 6 AM.

325
_posts/2018-02-17-logs-for-the-Community-meeting-held-on-2018-02-17.md Normal file
View file

@ -0,0 +1,325 @@
---
layout: post
title: Logs for the Community Meeting Held on 2018-02-17
summary: Community highlights, Forum Funding System updates, RFC-HWALLET-1, Localization workgroup, March HF, chain split discussion (e.g. MoneroV), and miscellaneous
tags: [community, crypto]
author: dEBRUYNE / fluffypony
---
# Logs
**\<sgp>** All right, meeting time :)
**\<sgp>** xmrscott rehrar ErCiccione serhack cryptochangement msvb-mob
**\<serhack>** Hello!
**\<sgp>** 0. Introduction
**\<cryptochangements>** Estoy aquì
**\<sgp>** We would like to welcome everyone to this Monero Community Meeting!
**\<sgp>** Link to agenda on GitHub: https://github.com/monero-project/meta/issues/178
**\<msvb-mob>** Hello.
**\<xmrscott[m]>** Salutations
**\<cryptochangements>** Hey everyone
**\<ErCiccione>** Hi!
**\<sgp>** Whoops, wrong link
**\<muchso>** hi all
**\<rehrar>** nah, let's discuss buildbot
**\<sgp>** Link to agenda on GitHub: https://github.com/monero-project/meta/issues/181
**\<sgp>** Monero Community meetings are a discussion place for anything going on in the Monero Community. We use meetings to encourage the community to share ideas and provide support.
**\<sgp>** 1. Greetings (continued)
**\<muchso>** who maintains buildbot? no source code?
**\<muchso>** need to add macos one
**\<cryptochangements>** Pigeons does builds afaik
**\<sgp>** 2. Community highlights
**\<sgp>** For a great weekly summary, please read the Monero Observer: http://monero-observer.com/
**\<sgp>** It seems like they are behind by a few weeks. Anyone have any large updates?
**\<rehrar>** I'm working on a big super secret project that is taking up basically 100% of my non-free time
**\<xmrscott[m]>** You'd want to ping moneroobydoo
**\<rehrar>** consider this a preannouncement
**\<sgp>** Thanks for the pre-announcement rehrar lol
**\<cryptochangements>** PUMP on the way
**\<rehrar>** *actual announcement* Monero popsicles!!
**\<cryptochangements>** Rehrar-gate anybody?
**\<sgp>** All right, we can jump into FFS updates
**\<sgp>** 3. FFS updates
**\<sgp>** There are several FFS updates.
**\<sgp>** a. RFC-HWALLET-1 project progress
**\<msvb-mob>** sgp: Thanks.
**\<msvb-mob>** We received our permanent USB product identifiers from pidcodes (a Opensource USB allocation.)
**\<msvb-mob>** We've studied current off chain bearer bond designs, for future Monero hardware
**\<msvb-mob>** projects.
**\<sgp>** msvb-mob msvb-lab
**\<msvb-mob>** Monerujo developer(s) really engaged with the hardware team to produce firmware in a new monerujo-hw project (online in their repository now.)
**\<msvb-mob>** Layout work is underway to create a new prototype, along the lines of the very first one called 'Breakneck.'
**\<msvb-mob>** Serhack helped us identify a cool graphical documentation system called 'board explorer' that we'll likely use in future web apps.
**\<msvb-mob>** The last few Julian Candy (second generation prototypes) are still available, in case somebody didn't get theirs.
**\<msvb-mob>** We're testing and learning about post restante, a method of blind delivery.
**\<msvb-mob>** Lastly, we have professional photos ready for production of a promotional video, but need help with that.
**\<sgp>** ooooh, sounds exciting :D
**\<msvb-mob>** In case anyone has the right tools and some time to make a video of prototypes with a background and music, like a one minute thing.
**\<msvb-mob>** sgp: Thanks a lot, I'm excited as well. That's all for us, I think.
**\<sgp>** Thanks msvb-mob. Does anyone have any questions for the hardware wallet team?
**\<msvb-mob>** Any questions?
**\<serhack>** amazing msvb-mob, did you try to contact savandra for the video?
**\<snorlax>** Yes, what timeline do you need for production of said 1 minute promotional video?
**\<fkjldsy>** is it prison wallet friendly? ie no hard corners
**\<msvb-mob>** By the way, I created a project landing page for Vegas 2018:
**\<msvb-mob>** https://taiga.getmonero.org/project/michael-vegas-august-2018/
**\<msvb-mob>** ...in case we need to organize for events there this year.
**\<xmrscott[m]>** Cool. I'll probably be at Vegas for Defcon again this year. If you need any help from me, ping me
**\<sgp>** @msvb-mob what is the timeline for the video? When do you hope to have it out by?
**\<msvb-mob>** Am I still connected?
**\<sgp>** I got the "am I still connected" message
**\<muchso>** me too (irc)
**\<muchso>** has the discussion stopped on irc?
**\<sgp>** Ok, well if he gets back online he can jump in again. For the sake of time, I'll move on to the second part
**\<sgp>** b. Localization workgroup Q&A
**\<sgp>** ErCiccione, do you have anything to discuss?
**\<ErCiccione>** yes,thanks sgp just a couple of things
**\<ErCiccione>** Localizations are going very well, a lot of volunteers these weeks. We basically filled the welcome page with flags. so Next release of the GUI will be available in a lot more languages. I don't remember the exact number but should be aboout 20
**\<ErCiccione>** Also about the GUI, all language files have been refreshed, these means that we need toupdate every language we already have. You can find a list of the languages and more info here: https://github.com/monero-project/monero-gui/issues/1116
**\<msvb-mob>** My connection is really poor, I'm just seeing the questions now and missed that chance to answer. Sorry.
**\<ErCiccione>** I also want to remind that to keep track of the work of the localization workgroup, there is everything on taiga (wikis and tutorials as well), and subscribe if you wish
**\<ErCiccione>** https://taiga.getmonero.org/project/erciccione-monero-localization/
**\<cryptochangements>** All languages have been updated since #1076 ?
**\<muchso>** from the git page looks like only two
**\<serhack>** I would like to remember that the getmonero.org website is going to be available in italian language! You can translate getmonero.org website by following these instructions! https://taiga.getmonero.org/project/erciccione-monero-localization/wiki/translating-monero-website
**\<ErCiccione>** cryptochangement: no, but many are in progress, theissue i linked to is for the missing languages
**\<serhack>** Let's translate Monero for everyone!
**\<ordtrogen>** Swedis will be done tomorrah
**\<cryptochangements>** Ok cool
**\<ordtrogen>** (misplaced an 'h' there)
**\<ErCiccione>** as serhack reminded us, we also need people to translate the website. On taiga every info, or please ask
**\<ErCiccione>** thanks serhack btw :)
**\<ErCiccione>** cryptochangements: also on taiga there is a list of WIP translations for everything. GUI, CLI ecc
**\<rehrar>** woo! go localization people!
**\<sgp>** Anything else ErCiccione?
**\<ErCiccione>** that's it from me. if anybody have any question...
**\<sgp>** Thanks ErCicicone and all the volunteers for the localization project!
**\<sgp>** Does anyone else have a FFS update?
**\<sgp>** All right, continuing on to 4. Hardfork discussion
**\<cryptochangements>** I've been adding a lot of stuff to https://github.com/monero-integrations/monerophp
**\<sgp>** Cool @cryptochangements
**\<serhack>** Hello! It's not a FFS update but an update about my work on the book! At the moment I have 112 pages of full text about Monero (and its community!). I am working hard on the content! Expect some news about my work next week!
**\<sgp>** Thanks serhack
**\<serhack>** :)
**\<sgp>** moneromooo, can you please discuss the major changes people should expect to see for the March hardfork?
**\<moneromooo>** There was pretty much nothing, so we just changed the PoW.
**\<moneromooo>** The one big thing there might have been is bulletproofs, but they were pushed to the subsequent one.
**\<muchso>** any date scheduled? need to know for the node-js pool
**\<moneromooo>** The PoW changes are minor, it stays mostly Cryptonight, we're just going to start tweaking it every fork as an extra preemptive defense against ASICs.
**\<moneromooo>** No height yet.
**\<sgp>** Ok moneromooo. So the other changes are improvements not related to consensus
**\<moneromooo>** It'll be in march, probably first half.
**\<moneromooo>** Non consensus changes... subaddresses. And multisig.
**\<moneromooo>** Subaddresses will need both sides of a tx to know about them, so it might take a while for, say, exchanges, to allow them.
**\<moneromooo>** Multisig, only the multi-signing party needs to.
**\<rehrar>** So all this talk about March 7th being the fork date is just a rumor moneromooo?
**\<moneromooo>** Yes.
**\<moneromooo>** Who said that ?
**\<cryptochangements>** I think thats what hyc said
**\<rehrar>** hold up
**\<rehrar>** https://www.reddit.com/r/Monero/comments/7y6cbl/when_is_the_hard_fork_of_monero/
**\<moneromooo>** Then maybe hyc's planning to do it :)
**\<sgp>** The update should also enable compact “fluffy” blocks by default, automatically send with the lowest priority to save on fees when the blocks have extra space, and a bootstrapping service where people can specify a remote node to use while the daemon is still syncing, correct?
**\<moneromooo>** Yes. I forgot aobut the bootstrap thing. I'm not sure the GUI will know about it yet, but there's another implementation of this already AFAIK.
**\<sgp>** Alright, thanks moneromooo
**\<sgp>** To those who are unaware, hardforks can be thought of as “protocol upgrades”.
**\<sgp>** Note that your coins are not at risk during this hardfork. All you need to do is update your software before you can send your coins again. You should update before the hardfork. Files will be available soon.
**\<sgp>** Now is the time for you to ask any questions regarding the hardfork :)
**\<rehrar>** when MoneroV?
**\<snorlax>** never, hopefully...
**\<moneromooo>** BTW, if your daemon is pestering you to update, that's because it's time based. Let it moan and update when the update is out.
**\<muchso>** yes the daemon shows it's time to update
**\<Dhjucjnejrfjf>** Speaking of monerov would it be appropriate to plan to add any exchange that supports it to the monero wiki avoid list since they are in essence helping to enable a privacy attack on monero?
**\<muchso>** that's ridiculous. just don't feed them
**\<ArticMine>** MoneroV should be a separate topic from out HF
**\<xmrscott[m]>** I would be in favor of that
**\<sgp>** Yeah, MoneroV will be up in a sec
**\<snorlax>** It's not ridiculous, but I have no opinion on it (sorry for spam.)
**\<sgp>** Looks like we're ready to move on to that section though. One last chance to ask a question about the Monero scheduled hardfork
**\<snorlax>** It's not ridiculous, but I have no opinion whether it should be done either way (sorry for spam.)
**\<sgp>** 5. Chain split discussion
**\<sgp>** Onslaught of text coming in, sorry :)
**\<sgp>** Another project plans to split Monero into their own project at some point in the future. This chain split has the potential to have significant consequences for the Monero network, since transactions that are made on both forks may share the same key image. With this information, they can link these transactions to the same sender, and they can likely learn which inputs in the ring signature are the real ones. Even wors
**\<sgp>** will have the chain reaction of invalidating this now-known input across other transactions that include it as a decoy.
**\<sgp>** I outlined these risks in a video I made yesterday: https://www.youtube.com/watch?v=TlVsMTeT_nE
**\<sgp>** Before you panic, there are several things worth noting:
**\<sgp>** 1. The attack will only be possible if many people use the fork
**\<sgp>** 2. The current mandatory minimum ringsize of 5 provides significant protection. For a chain reaction to occur, all 4 other inputs must be known false. A larger minimum ringsize would provide more protection.
**\<muchso>** I watched the video. is there a way to change the image key? will that be a problem with double spending?
**\<sgp>** 3. Historically, people tend to spend Monero in 2 days. It is likely that the attack will be mostly over after 2 days. However, this is not a given.
**\<sgp>** 4. If people do not spend their funds normally as discussed in #3, we should be able to figure this out and evaluate the risk potential.
**\<sgp>** What can you do? In one word, wait. Just wait after the split to see what is happening. Reasonably expect to wait a few days before sending funds. Stay updated during and after the split to see what other people are doing and what they recommend.
**\<sgp>** You can help the network by sending transactions to yourself. Make sure you do this among wallets you entirely control (eg: not exchanges, MyMonero). In this case, it doesn’t matter if the decoys are invalidated since you don’t need the protection of ring signatures when sending funds to yourself. Furthermore, you will generate new inputs that will not be invalidated that others can select.
**\<sgp>** All right, onslaught of text over. Any questions?
**\<sgp>** @muchso I do not believe changing the key image is possible, at least to our knowledge
**\<moneromooo>** "You can help the network by sending transactions to yourself." Can you elaborate on that ?
**\<muchso>** If the forkers change the way the image key is created, wouldn't that prevent it?
**\<endogenic>** moneromooo: i think he means generating more new txs
**\<endogenic>** outputs
**\<ArticMine>** The attack can be mitigated by using the same mixins on both chains for pre split inputs
**\<Dhjucjnejrfjf>** Good summary? Opinions on suggestion above for Reddit wiki avoid list exchange deterrent?
**\<endogenic>** mixable outputs\*
**\<sgp>** moneromooo if you churn after the fork, you create new outputs that will not be compromised later that other people can select
**\<rehrar>** since the key images are per output, ye?
**\<Dhjucjnejrfjf>** Let's let the exchanges know that the monero community will unite to boycott exchanges that support monerov
**\<sgp>** Of course, people don't know which ones are generated by churning, but if inputs are selected randomly, it will still help out
**\<ArticMine>** This requires that a pre fork input only use pre fork mixins
**\<rehrar>** so the key images will only be the same for the moments when the fork happens
**\<snorlax>** @ArticMine: what tools exist for that? Also @sgp elaborated on that point in the latter portion of his video: it's not a surefire way to protect yourself
**\<ArticMine>** I say mitigate not protect
**\<ArticMine>** We need th tools
**\<sgp>** @ArticMine, you are in favor of creating tools that allow people to select their own inputs manually?
**\<rehrar>** I think one tool that should be considered is a higher ringsize
**\<moneromooo>** It's really not clear to me that spamming the chain is useful.
**\<sgp>** @rehrar I have not run the speicifc numbers, but a higher ringsize would help. A higher proportion of inputs would have to be "compromised"
**\<cryptochangements>** I honestly dont know if that kind of tool would work. The average user simply wont use it and people mostly just want to dump the forked coins for "free money"
**\<rehrar>** I realize in the event that one output is the same for a given tx across the forks, that that is the real one, but even a marginal chance of having another common output when 'randomly' chosen is helpful
**\<rehrar>** would probably take the chance from 0.000001 to 0.000002% though :P
**\<moneromooo>** Spamming *their* chain with newly created outputs, though... ^\_^
**\<sgp>** @moneromooo that would be potentially damaging to Monero
**\<snorlax>** If every new transaction in a chain reduces the confidence of analysis by (ringsize) that appears useful to me, especially when my effective ringsize is going to be decreased by fork claims
**\<moneromooo>** Maybe, but that's not clear to me either. It's a complex system.
**\<sgp>** A higher ringsize means more inputs need to be compromised before the real input is known and chain reactions occur
**\<snorlax>** ... and more transactions means the same, yes?
**\<ArticMine>** I do not see how a higher ringsize helps if the input is compromised
**\<pca>** Is this MoneroV a bonafide adversarial attack vector? If so, does MRL have any input on this? Is the problem well understood? What is the worst case scenario? (apologies for all the questions)
**\<snorlax>** Add it to the mile-high stack of topics for the MRL to consider ^\_^
**\<sgp>** @ArticMine you're looking at the first wave of attack. I'm looking at the second
**\<muchso>** pca - was brought into attention only a week ago
**\<moneromooo>** AFAICT, it's a con vs users. Normally, to expose outputs, you'd need to generate lots of new outputs, paying fees. Here, they incentivize others to pay the fees for them, in return for promise of money... that they don't have to pay you.
**\<sgp>** @ArticMine a higher ringsize has NO impact if people reuse key images on both chains. The real input will be known regardless of the ringsize
**\<rehrar>** ArticMine since knowing a real output doesn't just affect the tx where the real output is spent, but also other rings that use that output as a ring member
**\<moneromooo>** So they rely on people thinking this has any value.
**\<moneromooo>** Which people will, because shitcoins.
**\<rehrar>** it's more to help prevent the domino effect from hurting too many people
**\<rehrar>** exactly, and the thing is, we cannot prevent this kind of fork from happening again and again and again
**\<sgp>** @ArticMine however, ince this input is known, it means all other transactions with this input are using it as a decoy. People can know this input is fake
**\<moneromooo>** It's quite clever, and machiavellian.
**\<cryptochangements>** As far as i understand it, a higher ringsize cant help people who reuse their own keys, but could help to protect other people who are minging their own business
**\<rehrar>** and even if the first twenty of them fail, what's to say the 21st won't catch on?
**\<rehrar>** since this is basically a free attack technologically (not socially)
**\<sgp>** @ArticMine Higher ringsizes reduce the risk of transactions having all decoys invalidated
**\<ArticMine>** The economics are very problematic. If people do not spend their MoneroV they are in effect propping up the value
**\<xmrscott[m]>** Hopefully MRL prioritizes it though given the chain split happens in roughly a month. This could all be averted if MoneroV created their own chain from avnew genisis instead of splitting
**\<ArticMine>** sgp yes but with after split inputs
**\<sgp>** Yes ArticMine
**\<cryptochangements>** xmrscott: But the 10x airdrop is the basis of their scam lol
**\<muchso>** most people are speculators they simply don't care
**\<rehrar>** xmrscott[m] we can never hope that people will act in good faith. In fact, when individuals are presented evidence of potential harm, and they choose to move forward anyways, we must assume bad faith
**\<snorlax>** I've seen several very good solutions that MoneroV could implement in order to maintain both our and their privacy. Perhaps extending those suggestions to them in a semi-official manner could mitigate the damage?
**\<snorlax>** Well, not solutions, but mitigations
**\<sgp>** @snorlax we need to assume they won't do anything to help out. In fact, we should assume they are attackers, since an attacker could try the same thing
**\<rehrar>** and even if MoneroV eventually does comply and has a new genesis block, that doesn't prevent a bad actor from doing what MoneroV is doing now in the future, and they will not be able to be convinced since they want nothing more than Monero's downfall
**\<ArticMine>** Which is the longer term issue the MRL can look into
**\<ArticMine>** Ehen they have some time
**\<ArticMine>** When
**\<muchso>** what solutions? MRL says it can't be mitigated
**\<snorlax>** @sgp I agree of course, but they have a vested interest in at least appearing legitimate. Extending a semi-official (read: via Monero contributors) solution for maintaining privacy at least puts the onus on them to implement, or get pointed out (again) as frauds
**\<rehrar>** as I see it, this is a huge hole and flaw in the Stealth addresses/RingCT/Ring signature coin, and, if not able to be solved, may be destructive enough over several iterations of this attack to move to another scheme
**\<rehrar>** but that's me thinking way in the future
**\<snorlax>** @muchso variations on forcing initial MoneroV transactions to use alternate rules or constructions in order to mostly-cleanly split the chains
**\<snorlax>** similar to the conversion of outputs from pre- to post-RingCT
**\<endogenic>** i tend to agree rehrar
**\<ErCiccione>** snorlax has a valid point imo. Even if it's very probable they won't to anything, it still worth to talk with them if there is a way to mitigate the problem
**\<ArticMine>** Yes but we must treat MoneroV as fully adversarial if we are to develop a solution from our end
**\<pca>** yep
**\<endogenic>** also agree
**\<snorlax>** Agreed with ArcticMine, pero... por que no los dos?
**\<rehrar>** See what we can do with MoneroV, but even if they agree, plan on MoneroV not being the last one
**\<ErCiccione>** ArticMine: absolutely
**\<rehrar>** and take this threat seriously
**\<sgp>** For these attacks to be serverely damaging, they need to control a large number of outputs
**\<rehrar>** Please note: while MoneroV is the first one to do this kind of attack, this is not a MoneroV attack per se, but a weakness of our current scheme.
**\<snorlax>** step one to controlling a large amount of outputs: dangle shitcoincash
**\<sgp>** So the priority should be convincing wallet providers and exchanges from supporting the fork
**\<rehrar>** So while it's upsetting that MoneroV is doing it, if they didn't, someone else would
**\<sgp>** @snorlax they need to possess a lot of Monero
**\<snorlax>** @sgp no they don't, they just need to entice users to reuse their key images. Or am I mistaken there?
**\<pca>** I dont think social intervention is the answer. (convincing exchanges, etc to not support it)
**\<sgp>** @snorlax yes, but they need to entice a large portion of the outputs
**\<snorlax>** I was alluding to the point above that previously, attacks cost tx fees (and/or XMR itself, in order to control/know outputs.) Now they're enticing users to reveal themselves
**\<muchso>** yeah that's not good. you seem to try to prevent users from getting their shitcoins
**\<snorlax>** @sgp I think we're on the same page, sorry
**\<rehrar>** pca while this is true, the whole point of Monero and crypto in general is that we should not need to rely on social answers, but rather replace these elements with potential for weakness in human corruption with provable cryptography, so as to be truly trustless
**\<ArticMine>** I am not sure about the exchange issue. I can see legal liability for exchanges if they do not at least allow users to Withdraw their MoneroV
**\<pca>** rehrar, I know that, hence my statement.
**\<rehrar>** ye, I agree that now social measures are the only action that can be taken with this specific instance of MoneroV
**\<rehrar>** but having to rely so heavily on it calls into question (at least for me) the strength of the current scheme
**\<moneromooo>** That shojuld never be the case. It's not users', since they don't have the secret keys.
**\<endogenic>** rehrar i agree it indicates something about Monero
**\<sgp>** Unless we agreed upon a larger ringsize
**\<muchso>** but a larger ringsize won't help would it?
**\<moneromooo>** Otherwise it puts the onus of all exchanges and other similar things to expend unbounded effort to give people what they think they're due.
**\<rehrar>** social measures should not be used indefinitely, but just temporarily while cryptography is developed so it's not needed anymore
**\<snorlax>** It helps if you don't reuse key images, but doesn't help you if you reuse your key image, @muchso. Larger ringsize concurrent with bulletproofs seems the way to go, imo
**\<sgp>** @muchso it would help mitigate the impact these compromised inputs have on other transactions
**\<muff1nman>** only issue being rehrar, is that temporary solutions set a precedence that is hard to overcome for future situations
**\<sgp>** We definitely have an issue here where the economic incentive will be to claim the coins. Which will harm privacy and the network
**\<rehrar>** the precedent is completely nullified when replaced with provable cryptography so the social measure that set the precedent is not needed period
**\<snorlax>** in lieu of a finalized cryptographic solution, however, the question of "why not both?" applies nonetheless--with MoneroV coming up within weeks, a bandaid--as temporary and ultimately unsatisfactory as it may be--may help nonetheless
**\<rehrar>** yes, snorlax, I agree.
**\<snorlax>** in lieu of a finalized cryptographic solution, however, the question of "why not both?" applies nonetheless--with MoneroV coming up within weeks, a bandaid--as temporary and ultimately unsatisfactory as it may be--may still help
**\<rehrar>** I believe temporary solutions SHOULD be utilized while research is done into permanent ones
**\<snorlax>** in lieu of a finalized cryptographic solution, however, the question of "why not both?" applies nonetheless: with MoneroV coming up within weeks, a bandaid--as temporary and ultimately unsatisfactory as it may be--may still help
**\<jeet.sidhu>** at least to reduce the damage
**\<rehrar>** in any case, I think MRL needs to focus on related research for the next while
**\<ArticMine>** The is a need for both. Short term mitigation and a long term solution
**\<rehrar>** and may constitute the need for an emergency hard fork after bulletproof schemes are vetted, so we can both reduce fees and raise ringsize when it's ready to help mitigate the domino effect
**\<sgp>** I'll try to come up with some models to quantify the attack better, but I'm not really an expert
**\<rehrar>** and all of the above is just a temporary solution while we look at either mitigating this attack entirely, or, if not possible, find a new scheme
**\<sgp>** The attack can happen in one of two ways:
**\<sgp>** 1. The attacker attempts to concentrate the reuse of key images to a certain point. Eg: claim your coins TODAY. This will have a stronger, but short-term impact
**\<sgp>** 2. Tries to spread them out. This will have a weaker, more long-term impact
**\<ArticMine>** 2) actually concerns me the most
**\<rehrar>** I think it's important to remember that, in the event that this attack cannot be reasonably mitigated, a failure of the current scheme is not a failure of Monero. :)
**\<sgp>** Case #1 actually concerns me the most. It increases the change of the ripple affect.
**\<rehrar>** the only failure of 'Monero' as a movement, would be if we fail to adapt
**\<rehrar>** Attacks are discovered all the time for all security and privacy software
**\<Guest70452>** telling people what to do with their private keys sounds desperate.
**\<ArticMine>** I have to agree
**\<sgp>** @rehrar with a very large ringsize, the only impact someone reusing their own key image has is on their own transactions
**\<ArticMine>** with Guest70452
**\<rehrar>** understood
**\<sgp>** Assuming that not everyone claims this reward. But even with a substantial portion, it can be mitigated with a large ringsize
**\<rehrar>** if the theoretical ring was the full number of outputs on the blockchain, then it would only hurt people making their own transactions
**\<muchso>** ringsize larger than 100 sometimes fail
**\<moneromooo>** Stop making me hungry rehrar.
**\<sgp>** @rehrar basically yes
**\<rehrar>** my primary concern is several insidious projects concurrently doing the same thing
**\<sgp>** So we need to come up with a number we feel mostly comfortable with. Suppose 25% claim the reward. 50%. 75%. 90%. Etc
**\<rehrar>** *shrug* sell Monero, buy Verge
**\<muff1nman>** even with much larger ring sizes, isnt the problem that you have two key images where there is a single matching input?
**\<rehrar>** too much drama
**\<sgp>** @muff1nman yes, but that only impacts the user who reveals this info
**\<rehrar>** yes muff1nman, but that affects the tx in question being made only, but there are other effects
**\<muff1nman>** ah okay thx
**\<rehrar>** such as when other ring signatures use that now 'known real' output as one of their ring members
**\<rehrar>** now you can discount that one as fake for sure, making the ringsize effectively one smaller
**\<muff1nman>** ah so in the case of a larger ringsize, using that ring member would have less of an account
**\<rehrar>** from 4 other ring members to 3 is a pretty dramatic decrease percentage-wise when compared with something like 10 down to 9
**\<muff1nman>** sure
**\<rehrar>** alright, we've run this through, let's move on? :)
**\<rehrar>** way over time here :D
**\<sgp>** We often go over for large discussions like these. Better than just cutting them off
**\<jeet.sidhu>** Does anyone know where to look for historical data on airdrops or forks? Like how many people claimed their bitcoin cash?
**\<rehrar>** yeah, but at this point everyone got out everything that can be said in a discussion like this
**\<sgp>** Any final thoughts? I'll look into this further and come up with some more data-driven thoughts
**\<ArticMine>** Excellent
**\<ErCiccione>** let'sclose this discussion with this tweet https://twitter.com/monero_v/status/964823517777850368
**\<sgp>** Good thoughts @jeet.sidhu. I will see what data is available
**\<ErCiccione>** you FUDers
**\<snorlax>** @jeet.sidhu see https://forks.network
**\<rehrar>** I agree with that tweet
**\<rehrar>** 100% agree
**\<rehrar>** better to have the flaw visible to thousands than known by a few
**\<pca>** One thing to keep in mind, is if there is a problem with Monero, MoneroV also inherits the problem. (and I bet they dont have the right people to fix it)
**\<muchso>** yep
**\<snorlax>** @jeet.sidhu you can see both BCH and BTG claims on that site
**\<sgp>** Ok, for the sake of time we will conclude the meeting.
**\<sgp>** 7. Confirm next meeting date/time
**\<rehrar>** tomorrow
**\<sgp>** The next community meeting will be two weeks from today on 3 March. The next Coffee Chat will be on 10 March.
**\<rehrar>** fine
**\<sgp>** Lol, you can hold your own special meeting tomorrow if you want. Just let people know about it :)
**\<sgp>** 8. Conclusion
**\<sgp>** That’s all! Thanks for attending this Monero Community meeting, and we hope to see you on /r/MoneroCommunity and #monero-community. Take care, and know that change starts with YOU.

202
_posts/2018-02-19-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-02-19.md Normal file
View file

@ -0,0 +1,202 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-02-19
summary: Multisig (paper), chain split (e.g. MoneroV), anonymity set, auditing options, and miscellaneous
tags: [community, crypto, research]
author: dEBRUYNE / fluffypony
---
# Logs
**\<suraeNoether>** allrighty, howdy everyone
**\<suraeNoether>** topic Research meeting now
**\<suraeNoether>** awww
**\<sarang>** hullo
**\<rehrar>** yeah!
**\<suraeNoether>** so
**\<sarang>** indeed
**\<suraeNoether>** before we get going, does anyone have any questions?
**\<rehrar>** pertaining to?
**\<suraeNoether>** anything, really. :P
**\<rehrar>** Are pancakes better with or without chocolate chips?
**\<sarang>** Well, I see the two big topics right now are output identification (a la MoneroV) and PoW change
**\<sarang>** at least for immediacy
**\<rehrar>** *shuts up to let smart people talk*
**\<suraeNoether>** oh, i think blueberries are better
**\<suraeNoether>** but that's none of my business
**\<suraeNoether>** yeah, i imagine at least some people have questions about how to keep their outputs safe with MoneroV and our PoW change discussion
**\<sarang>** I think a related question that's valid is "what do we plan to do about this?"
**\<suraeNoether>** but we can maybe hold that until the end of the discussion: basically, "what i've done this week" has been multisig. i have the paper down to low 20s pages, and i have one security proof left to complete, and i need to clean up the appendix describing our code.
**\<suraeNoether>** sarang before we move onto the more obvious stuff, want to give us a brief review of your week?
**\<sarang>** Sure, some course planning for the summer, reviewing SoWs and discussing with Benedikt, some paper reading
**\<rehrar>** Sorry, couple questions on multisig paper. 1. ETA? 2. Submit for peer review?
**\<sarang>** A lighter week than last
**\<sarang>** Oh, and writing up a talk on privacy coins for next month
**\<sarang>** (due this week)
**\<suraeNoether>** 1) ETA ... i am hoping to finish it today. so quadruple that and maybe i'll be 10% correct. :P
**\<suraeNoether>** we are definitely submitting it for peer review
**\<rehrar>** Nice! It will be 'White' no more
**\<suraeNoether>** i'm so close to finishign this thing, i'm hoping for mid-week to release the whitepaper version of it to the community and upload it (perhaps) to arxiv or something, after i get a brief review by sarang
**\<sarang>** Yeah, BPASE work threw a temporary wrench at it
**\<suraeNoether>** does anyone want to describe their work this week? I know chachasmooth has been learning about elliptic curves
**\<sarang>** but that's the nature of research
**\<sarang>** Well I am finalizing my privacy talk, which focuses on some definitions of privacy and compares privacy techologies used in coins today
**\<sarang>** It focuses heavily on Monero but tries to do a fair assessment of the playing field
**\<suraeNoether>** nice, i want to actually talk about a simplification of the EABE attack that is concerning to me
**\<sarang>** I was also asked to lead a one-day short course on data analysis at the SciPy conference this year, so I'm using blockchain data as the project
**\<sarang>** Some good PR and hopefully some interesting analysis we hadn't thought of before
**\<sarang>** Anyway, go ahead suraeNoether
**\<suraeNoether>** I'm thinking perhaps we need to put out a statement, because there is at least one very common scenario in which people think Monero is protecting them with signer ambiguity, but it really isn't
**\<suraeNoether>** and it's the EAE attack, actually, where someone buying something from you is colluding with a KYC exchange
**\<suraeNoether>** in this case, it should be obvious: Alice is surrounded by the KYC exchange, who knows her personal identity, address, etc, and also knows the one-time destination keys being used by Alice for these purchases they are making from you
**\<suraeNoether>** once the KYC exchange has collected a sample size of deposits from Alice, that KYC exchange can look into the history of these deposits and identify one-time keys that were flagged from earlier.
**\<sarang>** right
**\<suraeNoether>** unless alice makes an extremely expensive churn, the appearance of these flagged outputs will occur in the history of these deposits more often than chance would dictate if the ring signatures were being randomly created by other users
**\<suraeNoether>** there isn't a quick and easy solution to this, and users who are very concerned about their privacy should not send their monero to KYC exchanges
**\<sarang>** I think it brings us back to the nature of ring signatures in general
**\<sarang>** They're to offer plausible deniability
**\<sarang>** but statistics will always be a problem unless ring sizes are very large
**\<suraeNoether>** yes. it's objectively better than using something like bitcoin due to plausible deniability, but it's still concerning
**\<rehrar>** does this potentially point to, somewhere down the line in the future, moving to a more bullet proof (pardon the pun) scheme?
**\<sarang>** I think it has to
**\<suraeNoether>** yeah
**\<sarang>** Full anonymity set is the only guaranteed way to thwart statistical analysis
**\<sarang>** This, the MoneroV thing, they all tie in to ring intersections and statistics
**\<rehrar>** does STARKS also have full anonymity set?
**\<suraeNoether>** one of the things fluffypony asked me to look into when i first began this was looking into things like zk-snark sidechains, so we have been considering this for awhile
**\<suraeNoether>** they allegedly do, yes
**\<andytoshi>** rehrar: STARKs is just a tech
**\<sarang>** yes
**\<suraeNoether>** ?
**\<andytoshi>** it's for zero knowledge proofs
**\<sarang>** The goal is just to prove the output is valid
**\<andytoshi>** "full anonymity set" applies to some specific system
**\<sarang>** right
**\<rehrar>** ah, apologies
**\<suraeNoether>** yeah, the implicit quesiton is "would we be using starks to implement a full anon set"
**\<andytoshi>** the answer to that is no, it's not feasible. bulletproofs would be faster for that
**\<andytoshi>** and smaller
**\<andytoshi>** and BPs aren't quite there i think
**\<sarang>** I mean, this problem isn't limited to us
**\<suraeNoether>** starks is new, but so are BPs. i think BPs will allow us to get some impressively large anonymity sets
**\<sarang>** There is not a good, efficient way to handle it... zcash has the same problem with different sacrifices
**\<andytoshi>** yeah..pretty sure BPs have a faster prover than SNARKs
**\<suraeNoether>** sarang \^ this is also correct, most users who use zcash make transactions they wish to be kept private as a z-transaction, but they end up depositing to KYC exchanges as t-transactions
**\<rehrar>** so the answer is almost a social one, wherein people don't need to trade to KYC exchange, because they can purchase whatever they want in Monero
**\<rehrar>** \*one of the answers
**\<suraeNoether>** so, this is an *open problem* in some senses, but my point is this: the current wisdom about best practices is to churn a lot and you're good. but that's not the case without impractically large churns, and the best practice is merely to avoid KYC exchanges
**\<andytoshi>** KYC has nothing to do with whether you publish your transaction data on a blockchain, think exchanges are just too lazy to implement z-transaction support
**\<sarang>** Part of the social problem is an identification of what exactly you're trying to accomplish with hiding transactions
**\<sarang>** At what point does "plausible deniability" fall apart in the face of ring statistics?
**\<suraeNoether>** in general, if a business is a KYC business (say a local coffee shop who happens to know you), you still have a similar problem while using Monero. really the best advice is: if you like your privacy in Monero, don't send Monero to people who know your name
**\<sarang>** that's not clear
**\<suraeNoether>** sarang with a sufficiently large sample size, after the "attacker" has made a sufficiently large number of controlled purchass
**\<rehrar>** I guess it may be more of a economics question, but is plausible deniability enough for fungibility than absolute anonymity? Because to answer sarang's question: for the common folk, fungibility would be what they're after
**\<suraeNoether>** purchass = purchases, but purchass sounds like a really great stripper name
**\<sarang>** rehrar: sure, but an exchange or police or whatever can decide when their analysis reveals a "probably bad" output
**\<rehrar>** even if they don't know the word fungiblity :P No merchant or individual wants to go through the headache of checking each received coin for 'taintedness'
**\<sarang>** it's the same issue with burden of proof in the court system, IMHO
**\<suraeNoether>** rehrar: I believe plausible deniability with a large enough scope is fine.
**\<sarang>** Right, but there is not a definition of "large enough"
**\<sarang>** depends on the context
**\<sarang>** nor is there a good definition of "plausible deniability"
**\<gsee>** When Fluffy spoke at Coinbase, he suggested that maybe they would be more comfortable listing monero and meeting their KYC/AML requirements if they required users to provide their view keys. Would that damage privacy of others?
**\<suraeNoether>** gsee not at all, and in fact that's what the view key is sort of for
**\<gsee>** what if they also required users to provide key images so to prove a wallet balance?
**\<suraeNoether>** that would have pretty nasty consequences: coinbase would have a list of proven-spent transactions, reducing the effective ring sizes of all outputs
**\<rehrar>** What would it take to get some good research done on 'large enough' and 'plausible deniability' definitions, or at least try to get ballpark stuff?
**\<rehrar>** I think that's some pretty important stuff to be able to define within reason
**\<suraeNoether>** well, my working definition of "large enough" works like this
**\<gsee>** thanks suraeNoether, that's what I was thinking. Just wanted to doublecheck.
**\<suraeNoether>** let's say you churn N times with ring size R
**\<gsee>** On a similar note, I have to prove our balances to auditors once a year. Showing them view keys and key images might be a bad idea then.
**\<suraeNoether>** this means you have R\^(N-1) independent ring signatures, each with R members. and the question is: if Eve knows Alice has A different outputs on the whole blockchain, whcih has B outputs, and if all outputs are selected for ring signatures at uniform randomly, *how likely is it that we see one of Alice's suspicious one-time keys appear in one of these R\^(N-1) ring signatures?*
**\<suraeNoether>** how hard is it to *look like a random sequence of transactions?*
**\<suraeNoether>** anyway rehrar, i've been looking into it for awhile
**\<suraeNoether>** but for now i think we need to put out a statement that monero user keys interested in privacy should not be shared with a KYC exchange in any way
**\<rehrar>** logistics question for me, the website guy: Do we want to put this and any future bulletins under the MRL page on the website?
**\<rehrar>** Or just the repo is good enough with a link to it?
**\<scoobybejesus>** When is it time for MoneroV talk? I have a question. Sort of a two-parter.
**\<sarang>** Well, MoneroV is related
**\<suraeNoether>** essentially, if we want like... concrete cryptographic security, we would need to churn... a lot
**\<scoobybejesus>** Question: MoneroV key images. Let's say the MoneroV team chooses to acquiesce and change their key image by hashing another parameter (or something)...
**\<scoobybejesus>** If their key images are a Monero-key-image-hashed-with-something-else, does that mean there is no way (discrete log-wise) to "tie" pre-fork Monero key images to their respective key images in MoneroV?
**\<scoobybejesus>** Or - maybe a better way to ask - is there even a way to take an existing Monero key image, do something to it, have it be useful on the MoneroV chain as double-spend prevention, while still not being "tied" to the Monero key image from whence it came?
**\<suraeNoether>** rehrar I'm unsure on that
**\<suraeNoether>** scoobybejesus: we thought at first monerov could compute key images differently, but the algebra doesn't appear to work out without allowing double spends
**\<suraeNoether>** without some sort of wizardry anyway
**\<sarang>** Well with a hash scheme there would be no way to link them, no
**\<sarang>** But \^ to what suraeNoether sez
**\<suraeNoether>** the only way i know of to safely claim your monerov is to try to fashion the same ring on both chains
**\<suraeNoether>** hmm, what about doubly hashing the point P?
**\<suraeNoether>** nope, still have the double spend problem
**\<sarang>** yup
**\<sgp>** \^ assuming no chain reactions
**\<andytoshi>** you can hash every known key image with a per-chain salt, then require users reveal only the hashed key image for future spends (and BP that they hashed the key image correctly)
**\<andytoshi>** but that's waay more work than we can expect scammers to do
**\<suraeNoether>** oh yeah, i suppose you are also assuming your fellow ring members are also computing identical rings on both chains
**\<sarang>** oh andytoshi so you mean go back and retroactively update the used image list?
**\<sarang>** interesting
**\<suraeNoether>** andytoshi i almost feel like we should make it an easy to use utility so we can point to unsafe projects and say "how come they aren't using our safe-to-use BP utility to ensure they don't shit in the punchbowl"?
**\<sarang>** suraeNoether: I don't think you can shame them like that
**\<gsee>** should users consolidate outputs before the fork? just in case they're going to try to create the same ring on both chain, it would be easier to do with fewer outputs, right?
**\<suraeNoether>** feels like an easy public relations way to deal with malicious shit in the future like this
**\<suraeNoether>** gsee: sure, but you are (see above) relying on any ring members to do the same as you
**\<sgp>** Perhaps, it is a social attack after all
**\<suraeNoether>** if half of your ring members don't know what to do and spend their shit on both forks in a sloppy way, then your effective ring size shrinks in a chain reaction
**\<suraeNoether>** because their output is now provably spent and can be removed from any rings referencing it
**\<sgp>** And with ringsize 5, you would have to expect \~2/3 of transactions on MoneroV to use that tool
**\<suraeNoether>** sounds about correct. seems like a real easy way to part fools from their money. fluffypony don't we have a public relations firm now?
**\<suraeNoether>** monerov is a pretty brilliant social attack. probably not state actors because the result is a public de-anonymization instead of secretly gathering intel, but pretty brilliant
**\<suraeNoether>** i could be convinced its the cryptonote guys
**\<suraeNoether>** anyway, it is unsafe to use your key images on another chain, period
**\<suraeNoether>** if you broadcast your key images in general, you are also opening yourself up to transaction censorship
**\<gsee>** MoneroV might not be state sponsored, but the next one might be. Or a state may decide to bid up the price of moneroV in order to entice people to spend their moneroV
**\<suraeNoether>** yeah, maybe
**\<suraeNoether>** it's just, in general, key images are sort of like commitments to a transaction. Opening the commitment, sharing the key image, is part of broadcasting a transaction. it shouldn't be seen as a standalone piece that can be treated separately like a view key
**\<suraeNoether>** okay, so today we've spoken about my and sarang's work from this past week briefly, and we discussed the EAE attack (rehrar, pm me, don't make any changes until we've chatted with fluffypony and luigi1111 and moneromooo and others), and the MoneroV airdrop
**\<rehrar>** no changes will be made
**\<sgp>** I suppose now's a good time for me to ask if you think it's prudent to increase the ringsize to mitigate the damage of a chain split attack. If the costs are minimal compared to the benefits
**\<sarang>** any other updates or questions about other non-pants-on-fire things?
**\<suraeNoether>** I believe we can summarize the EAE attack as: don't use private money with non-private businesses (KYC exchanges in particular). in the meantime, I'm going to think about a threat model. and we can summarize the MoneroV airdrop as: don't use your Monero key images on the MoneroV blockchain. period.
**\<andytoshi>** sgp: to increase the ringsize dramatically will require new tech (RTRS or BPs)
**\<andytoshi>** just doubling it or something won't really help i think
**\<suraeNoether>** to increase the ringsize moderately will not be a sufficient protection against the EAE problem
**\<suraeNoether>** \^
**\<gsee>** i have a question. Not sure if this is the best place/time to ask, so we can take it offline if necessary. Is there any way to prove what my wallet's balance was on Dec 31st to an auditor if I have made transactions since then?
**\<suraeNoether>** i believe we don't see a lot of benefit until we get ring sizes in the 20s, last time I ran computations, but don't quote me
**\<sgp>** Won't help EAE, but would help chain split issue
**\<andytoshi>** gsee: yes but you'll need provisions or something
**\<andytoshi>** oh, no, just a view key + the public blockchain will be enough
**\<suraeNoether>** it would probably be sufficient to reveal to an auditor the private transaction key for each transaction, but that reveals a lot more information to the auditor than if you reveal the key images that you've spent
**\<moneromooo>** You see all incoming monero along with block heights, and you can scan the chain for the height a key image was spent, if any. So yes. The DB has no index for key image -> height-or-tx though, so slow.
**\<iDunk>** If he spent from tha wallet, then change would appear as new income.
**\<suraeNoether>** i imagine in most *legal* situations gsee, you could merely present a screenshot of your wallet balance
**\<suraeNoether>** tbh
**\<gsee>** that's what we're leaning towards right now. Actually having someone stand over my shoulder while I show the balance
**\<suraeNoether>** but if you reveal your key images, again, you are proving some outputs as spent to an auditor, which reduces the effective ring size of any other signatures depending on your keys
**\<suraeNoether>** gsee if that's an option, do it that way
**\<suraeNoether>** requires no cryptographic trickery
**\<suraeNoether>** meatspace is like... the best at keeping secrets
**\<suraeNoether>** in practice, most cryptographic protocols can be broken with a hammer or a 4 dollar wrench in a rather nasty sidechannel attack. :P
**\<sarang>** So, what's everyone's priorities for the next week?
**\<gsee>** ok. would be great if we could create better tools for the future that would let them verify independently. Maybe that's not possible without leaking too much info; especially if one auditor becomes widely used.
**\<sarang>** Since it's 18:00 now
**\<suraeNoether>** mmmultisig brother. talking with a few venues for the monero conference this week.
**\<suraeNoether>** oh i have an idea
**\<sarang>** Does anyone see any immediate action items regarding MoneroV etc?
**\<suraeNoether>** i feel like we need to put out a formal announcement on reddit or something
**\<sarang>** So we have no formal suggestion on ringsize re: monerov?
**\<suraeNoether>** ring size isn't going to help the monerov airdrop problem
**\<sarang>** Yes just confirming
**\<sarang>** So our messaging is consistent
**\<suraeNoether>** i know we just put out a joint statement on PoW and key re-use
**\<suraeNoether>** but i feel like MRL could write a reddit post like "Here's how to claim your Monerov safely: DON'T."
**\<sarang>** But I'll get 10x the money!!111!!!
**\<sarang>** While we're at it, I'll give you two shiny new nickels for that quarter you've got there
**\<suraeNoether>** gsee: to prove to an auditor you have spent some transactions you can (in terms of easy and insecure to hard and secure): 1) hand them your view and spend private keys. after the audit is over, send yourself money to a new pair of keys so you don't have to worry about the old ones being used to spend. rely on meatspace legal structure to protect you from theft by the auditor. this degrades not only
**\<suraeNoether>** your security but the security of all ring signatures dependent on your outputs. 2) hand them the key images of your spent outputs. you don't need to worry about the auditor spending your money, but this still degrades both your security and other folks' security. 3) ??
**\<scoobybejesus>** If there were a tool to produce identical rings... I haven't decided whether I'd take advantage. Without that tool, I'm definitely not interested.
**\<suraeNoether>** scoobybejesus: even then, if your other ring members go cash in and *don't* use that tool, your ring size just shrunk brother
**\<scoobybejesus>** true that ;)
**\<suraeNoether>** okay, until next week