4rkal/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2025-01-28 18:56:33 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #461 from dEBRUYNE-1/master

Browse Source 
Logs for the Community Meeting Held on 2017-10-28
This commit is contained in:
luigi1111 2017-10-30 13:24:35 -05:00 committed by GitHub
commit 7b6bd95f1d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 464 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

208
_posts/2017-10-28-logs-for-the-Community-meeting-held-on-2017-10-28.md Normal file
View File

@ -0,0 +1,208 @@
---
layout: post
title: Logs for the Community Meeting Held on 2017-10-28
summary: Community highlights, Forum Funding System updates, Monero meetup kit, 34C3, RFC-HWALLET-1, Monero integrations, upcoming meetups, community survey, and miscellaneous
tags: [community, crypto]
author: dEBRUYNE / fluffypony
---
*October 28th, 2017*
# Logs
**\<sgp>** Meeting is starting
**\<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/132
**\<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
**\<vp11>** hey there lovely people
**\<erciccione>** hi
**\<xmrscott[m]>** Salutations
**\<endogenic>** o/
**\<sgp>** 2. Community highlights
**\<sgp>** For a great weekly summary, please read the Monero Observer: http://monero-observer.com/
**\<sgp>** The Monero Observer’s FFS proposal has been fully-funded!
**\<sgp>** 3. FFS updates
**\<sgp>** There are several FFS updates.
**\<sgp>** a. Monero Meetup Kit
**\<sgp>** I don’t have anything to add here except that it is now in Funding Required: https://forum.getmonero.org/8/funding-required/88374/monero-meetup-kit
**\<sgp>** b. 34C3 congress preparations
**\<sgp>** @msvb-lab would you like to comment about this?
**\<michael>** Minute?
**\<sgp>** Anyone have anything to discuss regarding this event?
**\<sgp>** Ok, well if they join us, we can go back
**\<vp11>** i have a question
**\<vp11>** for the monero meetup kit
**\<sgp>** @vp11 go ahead
**\<vp11>** how the groups are going to be selected to receive the kit? do you already have an application draft?
**\<vp11>** i wouldn't apply because brazil is far away :P but I was just curious
**\<vp11>** and this gave enough time to msvb-lab to join :)
**\<sgp>** I will create an application form once the webcam covers arrive. For these first few kits, it will only be for groups in the US
**\<sgp>** serhack and I will discuss these. If anyone else would like to help also, PM me and you can help too
**\<msvb-lab>** Travelling a bit and screwey Internet. Sorry, I'm here now.
**\<vp11>** but are there minimum requirements that you have in mind? like number of people who will join the event, etc etc, or you're still brainstorming how it will work?
**\<vp11>** oh nice
**\<vp11>** that's cool
**\<sgp>** Target of 50 people at the event
**\<sgp>** So preference towards groups that have consistently had strong attendance
**\<vp11>** makes sense, thanks!
**\<sgp>** @msvb-lab feel free to jump in. I know you have several items you want to discuss
**\<msvb-lab>** sgp: Yes cool, parasew[m] are we talking about 34C3 here now?
**\<sgp>** Yeah
**\<msvb-lab>** We don't have anything concrete about 34C3 (the end of year large conferernce in Leipzig.)
**\<sgp>** Then you can talk about the hardware wallet after too
**\<msvb-lab>** Just want to announce we'll be present as Monero in the Cryptocurrency assembly.
**\<msvb-lab>** The hardware wallet forum post mandates that we do progress status reports in monero-dev meetings.
**\<msvb-lab>** ...but we moved away from them, so the question is if we're at home here?
**\<sgp>** I say you can have some, but don't get too technical here
**\<msvb-lab>** Some wanted to keep the monero-dev meetings software only.
**\<msvb-lab>** sgp: Then if nobody objects, we'll keep things neat and basic, and do status reporting here.
**\<sgp>** Anyone have any thoughts? Are high-level updates cool for everyone?
**\<vp11>** the community funded the project so it makes sense to share progress reports here, I don't see a problem with that. as @sgp said, just take care to not go super technical.
**\<msvb-lab>** Like now I can say that we're becoming a stable team and have created together a first prototype.
**\<msvb-lab>** https://taiga.getmonero.org/media/attachments/1/e/2/5/ee5db3efec91a39cab0f35f243f54513ac8437d56bd18cc8e5a2910f7c4c/assembled_flashed.jpg
**\<msvb-lab>** Photos are good for non technical discussion fodder, no?
**\<vp11>** cool pic
**\<msvb-lab>** A question, does anyone know where the source code went for the last state of Trezor Monero firmware port?
**\<sgp>** Photos are especially good
**\<vp11>** yeah, photos are great!
**\<msvb-lab>** Like this post basically killed the Trezor port:
**\<msvb-lab>** https://forum.getmonero.org/9/work-in-progress/265/adding-monero-support-for-trezor?page=&noscroll=1#post-1520
**\<msvb-lab>** ...but we can't find the firmware that was created up until that point.
**\<nioc>** msvb-lab: I forget who has the trezor "snap shot" but they might know in dev
**\<sgp>** @msvb-lab this is all I have, and the links are dead https://forum.getmonero.org/4/academic-and-technical/2495/experimental-trezor-firmware-testing
**\<vp11>** it's proprietary, right? does someone have it?
**\<msvb-lab>** sgp: Yes, we found lots of dead links too.
**\<msvb-lab>** vp11: Trezor firmware is Opensource.
**\<msvb-lab>** ...as we are of course.
**\<msvb-lab>** nioc: Hey cool, thanks for the advice. I'll check again in -dev.
**\<sgp>** It was NoodleDoodle
**\<msvb-lab>** sgp: NoodleDoodle still hangs out here, or mostly in -dev?
**\<vp11>** msvb-lab, didn't know that, thanks for the education
**\<sgp>** Mostly in -dev
**\<msvb-lab>** sgp: Okay cool, so this weeks 'status update' is rather unorganised due to travel, sorry.
**\<msvb-lab>** But that's all I have an can of course answer questions if folks are curious.
**\<sgp>** @msvb-lab no worries, we've all been there
**\<sgp>** Any questions for him?
**\<vp11>** no questions but I'm excited for this project :)
**\<vp11>** the progress reports will be welcome
**\<msvb-lab>** vp11: Cool, check out:
**\<msvb-lab>** https://taiga.getmonero.org/project/michael-rfc-hwallet-1-implementation/
**\<nioc>** sgp: somebody besides noodledoodle has it, I don't think he wants anything to do with it now
**\<msvb-lab>** ...and sign up as a tester or something.
**\<vp11>** amazing, will do!
**\<msvb-lab>** nioc: What would your strategy be for finding it, since 'somebody besides' == many people?
**\<msvb-lab>** ask on monero-dev right? If that's the strategy then I understood correctly.
**\<sgp>** -dev is the best place to ask
**\<nioc>** msvb-lab: I just remember it being disclosed in -dev
**\<msvb-lab>** nioc: Cool, thanks again.
**\<dEBRUYNE>** msvb-lab: https://github.com/prusnak/trezor-xmr/commits/master
**\<dEBRUYNE>** This is part of it
**\<nioc>** it might not be a dev but an long time community member
**\<msvb-lab>** dEBRUYNE: Interesting, that looks very good. Might be what we're after.
**\<vp11>** dEBRUYNE always comes to save the day
**\<sgp>** Yup :)
**\<sgp>** @msvb-lab anything else you want to discuss before we move on?
**\<msvb-lab>** sgp: No, thanks for giving me the chance to speak.
**\<sgp>** d. Monero Integrations
**\<sgp>** Serhack is busy today, but you can see the latest update on the work here: https://www.reddit.com/r/Monero/comments/7938pb/monero_integrations_update_10/
**\<serhack>** Hey :)
**\<sgp>** Oh, apparently he can still drop by!
**\<sgp>** @serhack anything else you want to add?
**\<serhack>** No :)
**\<serhack>** Expect some news soon
**\<sgp>** Cool. Everyone read the linked update if interested
**\<sgp>** 4. Upcoming Meetups
**\<rehrar>** Yay
**\<sgp>** There will be a Monero Meetup in LA on November 7th: https://www.meetup.com/preview/Monero-Los-Angeles/events/242968913
**\<sgp>** Does anyone know of other events coming up?
**\<serhack>** A secret project is cooming soon
**\<dEBRUYNE>** msvb-lab: there's these two too: https://github.com/jedigras/noodledoodle_xmr_trezor/commits/master & https://github.com/jedigras/trezor-xmr/commits/master
**\<vp11>** ohhhh these secret projects!!
**\<serhack>** Expect a b ... ops :)
**\<sgp>** I'll let serhack discuss it when he's ready, but it will require many volunteers
**\<sgp>** 5. Community Survey
**\<sgp>** xmr\_eric posted the results from his third survey, with over 500 responses: https://www.reddit.com/r/Monero/comments/794v43/monero_community_survey_3_results_over_500/
**\<sgp>** I want to take a few minutes and discuss the results.
**\<serhack>** Yeah @sgp. Not now
**\<serhack>** Monero community is awesome
**\<sgp>** We have a lot of active people!
**\<notcreative>** anyone know if there is an official remote note that I can connect to rather than local copy?
**\<sgp>** Did anyone find any of the results surprising?
**\<serhack>** But there are some "devs" that don't/ can't contribute
**\<serhack>** That's interesting
**\<vp11>** I did find the results very interesting
**\<sgp>** notcreative: no official ones, but check out moneroworld.com
**\<vp11>** I wanted even to discuss if we could do something to promote OpenAlias more.
**\<vp11>** I find it's a great feature for newcomers into the cryptocurrency scene.
**\<notcreative>** @sgp - Thanks
**\<sgp>** @vp11 I think we should promote it more to businesses
**\<sgp>** Most people don't own their own domain
**\<vp11>** indeed, business would love having their "main hot wallet" with something easy like monero@domain.com for payments.
**\<vp11>** I know there's a tutorial on monero.how
**\<vp11>** but maybe do a more graphic tutorial and promote it? I don't know. anyway, it's only one of the interesting points from the community survey.
**\<sgp>** I think OpenAlias is something people will not typically know of by name but understand how it works when they use it
**\<sgp>** Like not many normal people understand how DNS works but they know how to go to getmonero.org
**\<vp11>** exactly
**\<sgp>** Also, OpenAlias gets kinda messy if you need payment IDs
**\<sgp>** Poloniex couldn't use deposit.poloniex.com since they need a payment ID/integrated address
**\<vp11>** hmm that makes sense. I guess that while normal email providers don't support the option this will be something for "niche" only?
**\<vp11>** like institutions or websites asking for donation (no need for payment id)
**\<vp11>** or normal people with their own domains
**\<sgp>** It may be. I don't think it makes sense for anything requiring a payment ID
**\<vp11>** indeed
**\<sgp>** Anyone else have any thoughts?
**\<sgp>** Thanks xmr\_eric for making the survey, and thanks everyone who took the time to respond
**\<sgp>** 6. Open ideas time
**\<sgp>** It’s open ideas time! Feel free to propose your ideas to this discussion group, and feel free to comment on others’ ideas. If you disagree with the idea, please reply with constructive criticism. Thank you!
**\<msvb-lab>** I really like the monero.how site, didn't know it existed until today.
**\<sgp>** It's been some time since we've had an adequate discussion time during a meeting
**\<vp11>** monero.how is so good, seriously one of the best websites for monero out there
**\<sgp>** @msvb-lab knaccc has done a great job with it, hasn't he?
**\<msvb-lab>** I wonder if part of the meetup kit could be text based.
**\<msvb-lab>** Like a card with four links, a paragraph description, some simple stuff, a few diagrams.
**\<msvb-lab>** ...if I have stickers and stuff then I would keep this card together with them.
**\<sgp>** It will include flyers and this infographic (https://www.monero.how/monero-infographic). What do you think it missing?
**\<msvb-lab>** sgp: Cool, no that's most precicely what I had in mind.
**\<sgp>** Great
**\<msvb-lab>** Good to see that others have covered the need.
**\<vp11>** as I said yesterday, I'll donate the getmonero.com.br domain for the Monero Project once we get the localisation project for the website going. just wanted to say it here to make it official and logged on github :)
**\<vp11>** I'll use another domain for the brazilian community initiative
**\<sgp>** @vp11 keeping yourself accountable :P
**\<sgp>** I can't wait until the website is localized. Lots of work being done
**\<sgp>** Can anyone make a plush Monero cat? I would totally buy one https://www.reddit.com/r/xmrtrader/comments/791w4r/daily_discussion_friday_october_27th/doystjw/
**\<sgp>** Also a Monero sweater
**\<msvb-lab>** We don't really have a mascot do we? Maybe it should be a cat.
**\<vp11>** msvb-lab, we kinda have
**\<vp11>** it's monero cat
**\<msvb-lab>** vp11: How does one know this?
**\<sgp>** https://ip.bitcointalk.org/?u=http%3A%2F%2Fi.imgur.com%2FFpEboZL.png&t=581&c=fHuK94WKFrPfhg
**\<sgp>** From an old Bitcointalk post
**\<msvb-lab>** Wow, very nice.
**\<sgp>** From hitbtc lmao https://bitcointalk.org/index.php?topic=583449.msg7527905#msg7527905
**\<vp11>** msvb-lab, there's even comics about Monero Cat, come on man.
**\<vp11>** https://www.reddit.com/r/Monero/comments/78wctn/who_is_monero_cat_episode_6_for_oct_26_is_out/
**\<vp11>** I want a Monero sweater, gonna ask my mother to make me one.
**\<sgp>** I created this really long post earlier this week: https://steemit.com/monero/@sgp/7yjqso-a-monero-introduction-for-beginners
**\<sgp>** Does anyone have constructive criticism of it?
**\<vp11>** only destructive ;) not really, I thought it was a good read.
**\<msvb-lab>** sgp: You saved that until the end? Nice thing to read, I'll definitely be checking it out. Diagrams are great.
**\<msvb-lab>** Speaking of saving until the end, I forgot to mention that anonimal and I were interviewed by BTCManager:
**\<msvb-lab>** https://btcmanager.com/interview-monero-hardware-wallet-pioneer-michael-schloh-and-kovri-dev-anonimal/
**\<vp11>** cool, I really like btcmanager, it's one of my favorites website. will surely check it out, thanks for sharing msvb-lab
**\<sgp>** Yeah, btcmanager has written some solid articles lately
**\<msvb-lab>** We have a journalist there on our side.
**\<rehrar>** Yeah
**\<sgp>** Does anyone have any final remarks?
**\<rehrar>** Nah
**\<vp11>** love you all guys :)
**\<sgp>** 7. Confirm next meeting date/time
**\<sgp>** The next meeting will two weeks from today on 10 November at 17:00 UTC.
**\<sgp>** Keep in mind that the second Monero Coffee Chat is next Saturday 4 November
**\<msvb-lab>** Thanks for moderating sgp[m], see you all later.
**\<sgp>** In future discussions, I would like to focus the conversation around using social media and getting some new faces involved here
**\<vp11>** nice, do we already know what platform we will be using next time?
**\<sgp>** I've been in dicussion with Jitsi and they're convinced our bug is incredibly rare, so we will use that again. However, it will actually be streamed to YouTube this time for most people to view
**\<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.

256
_posts/2017-10-30-logs-for-the-Monero-Research-Lab-meeting-held-on-2017-10-30.md Normal file
View File

@ -0,0 +1,256 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2017-10-30
summary: Multisig, hash-based accumulators, blockchain protocols, quantum-hard shuffle PRNG, educational outreach, and miscellaneous
tags: [community, crypto]
author: dEBRUYNE / fluffypony
---
*October 30th, 2017*
# Logs
**\<sarang>** Let's go
**\<suraeNoether>** Welcome everyone, to our second official (third unofficial) research meeting. fluffypony dEBRUYNE luigi1111 knaccc
**\<suraeNoether>** uhm... ArcticMine... uhm... who else should we ping? moneromooo
**\<luigi1111w>** official counts toward unofficial?
**\<suraeNoether>** endogenic
**\<suraeNoether>** is an official meeting also unofficial? is it a subset relation? anyway
**\<suraeNoether>** kenshi84 too
**\<suraeNoether>** ok so, I don't really have an agenda. I want me and sarang to share with the group what we've been doing these past few weeks, and if anyone else has been doing any interesting research, let's talk about it
**\<suraeNoether>** sarang, you wanna go first?
**\<sarang>** Sure
**\<sarang>** I've been working a lot of readings mainly on some interesting new stuff
**\<sarang>** Hash-based accumulators are becoming a thing
**\<sarang>** where you can use interesting pairing relations to prove membership or nonmembership in a set
**\<sarang>** the nifty part is that the manager of the set is untrusted
**\<suraeNoether>** you've mentioned those several times. are all hash-based accumulators based on pairings crypto?
**\<suraeNoether>** or are you using pairing differently
**\<sarang>** Oh, I mean the structure involves pairs of elements as opposed to single elements
**\<suraeNoether>** ah, ok
**\<sarang>** This is a newer structure that gives nice efficiencies
**\<suraeNoether>** so can we use a hash-based accumulator without a trusted set-up to do something *akin* to ring signatures?
**\<sarang>** That's my interest
**\<sarang>** The security models would have to be analyzed in that new context
**\<silur>** sarang does the order of these pairs have any effect on the security?
**\<sarang>** None
**\<silur>** okay
**\<sarang>** What it does
**\<sarang>** is give you a fast way of demonstrating membership or nonmembership
**\<sarang>** by using the pairings akin to an ordering
**\<hyc>** ... reminds me of bloom filters, fast set membership
**\<suraeNoether>** hyc i'm sorry i forgot to ping you
**\<hyc>** no prob
**\<sarang>** I've also been continuing investigations into aggregate signatures, something surae brought to my attention a while back
**\<sarang>** the idea being that you can compress a set of signatures down to a single one
**\<suraeNoether>** hyc bloom filters do fast set non-membership, not fast set membership, but both are based on hashes
**\<sarang>** Verification is still linear
**\<sarang>** but space is constant
**\<sarang>** There is of course a downside, which is that it requires a bilinear map between groups with particular properties
**\<sarang>** It's apparently still an open question whether it's possible to construct an aggregate that doesn't require full linear verification
**\<suraeNoether>** i didn't realize agg sigs used pairings
**\<sarang>** The ones I've seen use bilinear maps to allow for third-party verification
**\<sarang>** It's a clever and fairly simple setup
**\<suraeNoether>** i found a few new sorts of signatures we maybe could look into, i have a list
**\<sarang>** What gets into the weeds is the way the security models account for it all
**\<sarang>** And there are some caveats dealing with repeated messages
**\<sarang>** Of course, subaddys went out already
**\<sarang>** SPECTRE is something that's on the radar for surae and I
**\<suraeNoether>** andytoshi linked his slides about atomic swaps and at least one type of sig i'm not totally familiar with was mentioned, and I forget what it's called. Aggregator signatures? or something like that.
**\<sarang>** And I'm still working on new work on proofs of proof-of-work
**\<sarang>** that, if implemented ideally, could offer significant savings in blockchain space/analysis
**\<sarang>** Logarithmically
**\<suraeNoether>** the past several weeks, i've been putting several hours a day into multisig... current version I will link tomorrow. I have had to modify the scheme to take into account multiple outputs, which isn't a huge deal, but changed notation throughout the paper pretty significantly, so
**\<sarang>** It's an ever-moving target
**\<suraeNoether>** i will link the current version tomorrow after i give it yet another read-through
**\<suraeNoether>** yeah, ring multisignatures are delicate
**\<suraeNoether>** but i've also been looking into spectre, as sarang mentioned
**\<suraeNoether>** i have a current working implementation on my github... but it takes quadratic time N^2 to organize N blocks
**\<suraeNoether>** which is not scalable
**\<sarang>** You wanna mention that email?
**\<suraeNoether>** i contacted Sompolinsky, one of the authors
**\<suraeNoether>** yeah
**\<suraeNoether>** I asked about the constant-time implementation they claim, and he got back to me
**\<suraeNoether>** my intuition about how to make this constant time was correct.... the algorithm can determine the order of leaves without any input from parents, grandparents, or grand\*parents of those leaves
**\<suraeNoether>** so working from the leaves backwards, and only organizing a constant number of blocks is sufficient to get computation time down to constant
**\<sarang>** But at a yet-to-be-analyzed cost
**\<suraeNoether>** which is sort of a cheat
**\<suraeNoether>** yes
**\<suraeNoether>** there is an attack where someone purposely chooses a block deep into the blockDAG
**\<suraeNoether>** this forces each node on the network to organize deeply into the blockDAG, which best case is a quadratic experience. pretty nasty.
**\<suraeNoether>** my first thought was our traditional split between full nodes and lightweight nodes
**\<sarang>** So it struck me as basically a DoS?
**\<suraeNoether>** uhm... kinda. it's DoS in the sense that ostensibly *honest* blocks can be used in the attack
**\<suraeNoether>** and it's not really an attack in a security sense, it's an attack that forces miners to blow CPU power
**\<sarang>** Right
**\<sarang>** That's what I mean
**\<suraeNoether>** so my first thought was full nodes that organize the top 2% of the blockDAG all the time, and lightweight nodes that only go back a certain \# of generations from the leaves and avoid blocks too close to the genesis block
**\<suraeNoether>** both sorts of nodes can do their thing in constant time. the full nodes will have larger constants, the lightweights will have smaller constants
**\<sarang>** So this reminded me of the discussion from a while back about ignoring blocks that are old enough
**\<sarang>** and the pros and cons of doing so...
**\<suraeNoether>** well we already reject blocks if their timestamps are outliers
**\<sarang>** So you think maybe the attack is irrelevant due to the time constraint?
**\<suraeNoether>** the timestamp isn't really the problem, it's where the block is placed in the tree. and we can't really reject blocks that are too deep into the blockDAG, because I don't see a good way for two different miners to agree what "too deep" means
**\<suraeNoether>** i think doing a full/light sort of split as above will avoid the attack for the most part, but it will tweak incentives
**\<suraeNoether>** but it's ... tricky
**\<suraeNoether>** anyway
**\<suraeNoether>** that's what i've been doing
**\<suraeNoether>** oh, on multisig, I mentioned this earlier this week, but i'm getting quite confident we'll be done with it pretty soon. code review is moving forward bit by bit (heh)
**\<suraeNoether>** is anyone else working on any interesting projects? i know that we've had discussions in here recently about PRNG and such, and I'm curious about what people are working on
**\<sarang>** Oooh yes, PRNG
**\<sarang>** I have no further updates, since I'm not sure if the devs took any definitive action it
**\<sarang>** There was also an observation about the use of keccak vs. SHA-3
**\<silur>** I'm working on a quantum-hard shuffle that can be used to construct PRNG-s
**\<suraeNoether>** silur: freaking awesome. by "working on" do you mean... writing a paper? working on code?
**\<silur>** writing a paper
**\<suraeNoether>** and what makes a shuffle "hard"? trying to un-shuffle?
**\<sarang>** Determining the end state w/o going through all steps?
**\<silur>** trying to reveal the previous state of the elements of the set
**\<silur>** or "peeking under the cards"
**\<sarang>** Nice, so it's a one-way function
**\<suraeNoether>** yup
**\<suraeNoether>** very cool
**\<suraeNoether>** are you a student, a professor, a hobbyist, silur?
**\<suraeNoether>** i still haven't read that shuffle paper you sent me :(
**\<silur>** I'll be a prof from next september on crypto
**\<sarang>** Congrats!
**\<suraeNoether>** congratulations!
**\<silur>** I'm at the edge of leaving ethereum foundation currently
**\<silur>** thanks :)
**\<sarang>** Any other interesting projects?
**\<sarang>** Or suggestions on directions to go?
**\<unknownids>** congrats!
**\<suraeNoether>** i'm also reading up on succinct posets, which are ... a new datastructure. btw for anyone curious, every DAG induces a poset and every poset is a DAG
**\<suraeNoether>** data structure\*
**\<sarang>** Yeah, that poset paper looks quite interesting
**\<suraeNoether>** they are significantly more compact than representing a DAG using upper triangular matrices, and they allow for constant time to determine whether one item precedes another
**\<sarang>** I find the tradeoffs between storage and time to be always fascinating
**\<suraeNoether>** so using those instead of the data structures i was coidng is going to lead to about a 75% reduction in computation time (but that's still quadratic...)
**\<silur>** wow
**\<suraeNoether>** https://arxiv.org/pdf/1204.1957.pdf
**\<suraeNoether>** and lastly, one more thing i'm kind of casually thinking about is andytoshi's idea for outputs where "addresses change." my best idea so far is to have each output be addressed to a *set* of destination addresses, each with their own timelock, but all sharing a key image (somehow)(
**\<suraeNoether>** really the challenge is to come up with a representation of a single key image for a single output but with multiple destination addresses each with their own timelock
**\<suraeNoether>** or rather: this would be one possible solution to the atomic swap refund transaction problem andytoshi brought up the other day.
**\<suraeNoether>** and that's all i have been working on
**\<suraeNoether>** other than silur, is anyone working on anything fun?
**\<suraeNoether>** or not fun as the case may be
**\<sarang>** http://nick.mtvnimages.com/nick/promos-thumbs/videos/spongebob-squarepants/spongebob-squarepants-fun-song-16x9.jpg?maxdimension=&quality=0.60
**\<suraeNoether>** okay
**\<moneromooo>** About PRNG: I ported the Bitcoin PRNG to monero, it's on github if anyone is curious.
**\<moneromooo>** I added a contentious patch, so that one will either go, or be modified.
**\<suraeNoether>** is the PRNG the contentious part or?
**\<moneromooo>** I added seeding from /dev/random at startup.
**\<sarang>** Can you link moneromooo ?
**\<suraeNoether>** oh i see heh
**\<moneromooo>** smooth thinks it should only be done if getrandom is not used, so I'll probably do this.
**\<suraeNoether>** i don't know enough about the various pros and cons of that approach to have an opinion
**\<suraeNoether>** on an administrative level, sarang: any word on the weekend course for talented high school students thing? i'm going to contact folks at the local universities around me this week to feel out the possibilities for a 2018 1-week summer workshop for undergraduates.
**\<moneromooo>** https://github.com/monero-project/monero/pull/2731
**\<suraeNoether>** thanks moneromooo
**\<sarang>** Ah yes, thanks for the reminder surae
**\<sarang>** So there has been interest expressed in two school programs
**\<suraeNoether>** if you want we can collab on the proposal for the springtime one
**\<sarang>** One would be a longer-term effort to work with North Carolina STEM students
**\<sarang>** A shorter but logistically-simpler one is with Duke University for a spring weekend course for gifted high schoolers
**\<sarang>** That's a bit tougher due to the extremely short course time
**\<suraeNoether>** yeah, i like the idea of spending a week or three with undergrads to teach them about crypto and maybe fork bitcoin or monero and mess with the code or something.... but i'm not so sure how much we can even do over one weekend with high school students
**\<sarang>** So maybe it's better to nix the weekend course idea and try for the longer course?
**\<sarang>** I don't have a good sense of the logistics required for that
**\<sarang>** But I'm investigating still
**\<sarang>** Another option is to do a Duke summer program that's 3 weeks long
**\<suraeNoether>** sarang let's try to set aside a few hours this week to figure out logistics of this. i would love for the monero community to fund up some education programs. that's good PR for everyone, and starts a pipeline of education into the cryptocurrency world... but i don't want to burden the monero community unnecessarily (for one thing) and if we can get a university to devote some money to this too, it
**\<suraeNoether>** adds legitimacy
**\<sarang>** The Duke summer one wouldn't require any funding from the community
**\<sarang>** since students are paying to go to it
**\<suraeNoether>** ok, so we have the Duke TIPP thing as a possibility there to reduce the burden on the community
**\<sarang>** Yep, and because they already have a supply of gifted students identified
**\<suraeNoether>** and maybe the first summer we should do something like that rather than taking point ourselves on organizing the program
**\<sarang>** Let's talk about that option
**\<suraeNoether>** cool
**\<sarang>** I've proposed new summer courses before. It's more involved than the weekend ones, but not bad at all
**\<sarang>** We both meet the instructor qualifications
**\<suraeNoether>** can you put out feelers in that direction and then we can talk about the responses you receive later this week?
**\<sarang>** Can do
**\<suraeNoether>** cool
**\<sarang>** I need to find the timeline for new course proposals for the summer. We may have missed it already
**\<suraeNoether>** oh, that would suck
**\<sarang>** Yeah, I'll check
**\<sarang>** They're always hunting for new STEM courses though
**\<sarang>** So they might make an exception
**\<sarang>** especially for me :D
**\<suraeNoether>** ok, maybe make a call or shoot an email today then, keep me updated
**\<suraeNoether>** okay, anyone else have anything they want to discuss?
**\<sarang>** Just emailed the bosses
**\<suraeNoether>** cool
**\<suraeNoether>** Okay, well if no one has anything else for now
**\<knaccc>** I was kinda wondering if you could give a brief explanation of whether bileanear pairings might be good for the future, for people like me who have no idea what it means
**\<suraeNoether>** aha
**\<sarang>** Surae, wanna take this?
**\<suraeNoether>** actually not at all
**\<knaccc>** hehe
**\<suraeNoether>** ha
**\<suraeNoether>** okay i will
**\<sarang>** lol
**\<suraeNoether>** ok knaccc so... bilinear crypto is essentially a way of taking an easy group and gluing it with hard group into a pair. And you do operations on the pair of curve points instead of an individual curve point. tthis is on it's own, useless
**\<silur>** surae you just opened a world before me saying that posets are isomorphic to DAGs how I didn't notice this \<3
**\<suraeNoether>** silur my dissertation is aaaaaal about po-groups
**\<suraeNoether>** if, however, you have a "bilinear pairing"
**\<suraeNoether>** you can move stuff from one of these two groups to the other
**\<knaccc>** so bilinear pairingss still use e.g. curve25519/ed25519?
**\<sarang>** One useful case is aggregate signatures that use exponentiation
**\<suraeNoether>** afaik there are not many curves compatible with bilinear pairing
**\<sarang>** The transfer between groups is what allows for verification
**\<suraeNoether>** hence CSW's weird meltdown on twitter
**\<knaccc>** ah so it'd be a diffferent curve that would have to be used then?
**\<sarang>** Yeah, it's an idealization right now
**\<suraeNoether>** so, a really dumb way to describe it is: if i need to know something about (A,B+C), I can hit it with the bilinear pairing e and treat that like (A+C,B)
**\<suraeNoether>** or rather
**\<knaccc>** and what's an easy group vs hard group?
**\<suraeNoether>** oh, like Zq versus X25519
**\<knaccc>** oh i see
**\<suraeNoether>** with bilinear pairings, the DDH problem is trivial to solve
**\<sarang>** You can also look at hardness as meaning hardness assumptions of problems
**\<sarang>** yeah
**\<suraeNoether>** *nod*
**\<sarang>** So the security definitions get really picky, for good reason
**\<knaccc>** are you aware of any performance implications of bilinear pairings
**\<suraeNoether>** yeah so, a linear function is one that behaves like this: f(a\*X + b\*Y) = a\*f(X) + b\*f(Y). a *bilinear* function has two inputs instead of one, (a\*X+b\*Y, c\*Z + d\*W), and it behaves linearly in each coordinate
**\<suraeNoether>** knaccc i am not
**\<sarang>** It would depend on the groups and the mapping
**\<sarang>** I think the current implementation limitations mean there hasn't been solid analysis on that yet
**\<suraeNoether>** did everyone see Craig Wright embarassing himself about this stuff, btw? on reddit and twitter
**\<sarang>** Also depends on our use case
**\<sarang>** Signature aggregation is just one application that sparked our interest
**\<sarang>** No!
**\<sarang>** Link plz surae
**\<knaccc>** can you define signature aggregation?
**\<suraeNoether>** oh haha
**\<suraeNoether>** https://www.reddit.com/r/Bitcoin/comments/79bnox/vitalik_and_uandytoshi_calling_out_csw_for_his/?utm_term=7fd17439-49d1-4d0f-90c7-a42272b3f896&utm_medium=search&utm_source=reddit&utm_name=frontpage&utm_content=1
**\<suraeNoether>** CSW claims he invented bitcoin and he used the secp256k1 curve because it's compatible with bilinear pairings
**\<silur>** ahahhaha :D
**\<suraeNoether>** and while that is kind of technically true, you need to store 10^70 or more bits, you know, a number comparable to the number of particles in the universe
**\<suraeNoether>** very entertaining read
**\<suraeNoether>** knaccc sig aggregation is a way of taking one or more signatures and combining them into a single signature, aggregating them
**\<knaccc>** for the purposes of saving space, verification time, both?
**\<sarang>** knaccc you save space
**\<sarang>** it's constant in the \# of sigs
**\<sarang>** verification is currently linear
**\<sarang>** there are implications for things like certificate chains etc.
**\<knaccc>** ah that leads me to my last quick question: i think someone mentioned that it was 'provable' that verification time had to be always linear
**\<suraeNoether>** well, ruffing proved that a ring sig scheme is linear in verification time
**\<sarang>** Agg. sigs are not ring sigs
**\<knaccc>** ah ok that was my question. it's ring signature specific then
**\<knaccc>** aha
**\<sarang>** They can be completely independent sigs
**\<silur>** do we have the updated ruffCT paper?
**\<knaccc>** i see
**\<sarang>** and in fact the messages have to be distinct
**\<knaccc>** cool thanks sarang suraeNoether
**\<silur>** I started on overview on that but sarang and surae told me it's outdated
**\<suraeNoether>** silur i can email you the copy i received from ruffing, but the bootle paper isn't private and ruffing's scheme is "Bootle + regular old multisig"
**\<suraeNoether>** https://eprint.iacr.org/2015/643
**\<suraeNoether>** silur the ruffCT scheme basically does this: for each output used in the signature, build a row of a matrix, entries are ring members. for each column of your resulting matrix, you should have a commitment to an amount, and the signature is essentially proving with an NIZK proof that you can open one of the commitments to zero
**\<suraeNoether>** the idea is that you know the actual keys in one of those columns
**\<suraeNoether>** but the code on the github is functional and up to date, and if you compare it to the bootle paper i'm pretty sure you'll be able to figure it out without me needing to ask ruffing for more permission to share his paper that says "DO NOT SHARE" on the top lol
**\<silur>** okay thanks
**\<suraeNoether>** okay, everyone, I think I'm going to call this meeting (seems like knaccc ran out of questions)