12:54:10 <sarang> Preprint on cross-input correlations: https://arxiv.org/abs/2001.04827
17:03:03 <sarang> Reminder that the research meeting is today at 18:00 UTC (about an hour from now)
17:03:14 <suraeNoether> Haha I thought it was now
17:03:17 <suraeNoether> #footgun
17:03:26 <sarang> negatory
17:03:53 <sarang> Plenty to discuss?
17:08:31 <derpy_bridge> [keybase] <surae>: Nope just clsag edits are coming to a close, and I am looking into a route that *may* but is unlikely to give a speedup
17:08:46 <sarang> With CLSAG?
17:08:52 * sarang is on pins and needles
17:28:02 <suraeNoether> Oh, no: triptych
17:28:25 <suraeNoether> I need about two hours at my whiteboard but it's currently occupied by matching coding notes
17:28:44 <sarang> roger
17:28:53 * sarang is still on pins and needles
17:36:34 <suraeNoether> Basically there are some standard approaches using the sumcheck protocol that can securely offload verification costs to the prover
17:36:59 <suraeNoether> I want to see what I can see
17:37:42 <suraeNoether> Worst case, it's something to keep in mind for future protocol design post-triptych, even if it isn't applicable to triptych at all
17:37:54 <rehrar> suraeNoether: is a monkey see monkey do kinda guy
17:41:22 <suraeNoether> Spartan uses it, and I was considering implementing Spartan to ensure I understand how it works, and then compare triptych-style proofs within the Spartan framework compared to vanilla triptych
17:43:31 <suraeNoether> rehrar: I would have a lot more publications if research proceeded that simply for me.
17:49:25 <rehrar> sgp_: let's just have it now
17:49:45 <sarang> ?
17:49:45 <sgp_> rehrar: wrong chat? lol
17:50:05 <rehrar> oof. Sorry.
17:50:21 <rehrar> I....meant.....a research party!!
17:50:23 <rehrar> heh
17:50:28 <kinghat> o_O?
17:51:57 <koe> remember, it can take a month for drug tests to come back negative rehrar
18:00:14 <sarang> OK, it's just about time to start the meeting
18:00:50 <suraeNoether> Indeed
18:01:06 <suraeNoether> Please take the lead sarang~
18:01:12 <sarang> Righto
18:01:13 <sarang> GREETINGS
18:01:28 <sgp_> hello
18:01:30 <almutasim> Hi.
18:01:34 <ArticMine> Hi
18:01:50 <koe> hi
18:01:53 <vtnerd> hi
18:02:06 <suraeNoether> Wow what a turnout!
18:02:48 <atoc> Hello
18:02:56 <rehrar> hi
18:03:22 <sarang> Let's continue with ROUNDTABLE discussion
18:03:30 <sarang> suraeNoether: anything of research interest to share?
18:04:16 <xmrmatterbridge> <ajs> ajs archived the channel.
18:05:08 <sgp_> um.... is the channel now gone on Mattermost?
18:05:15 <suraeNoether> not yet... Right now I'm just copy editing CL sag, working on matching code, and looking into possible speedups for triptych
18:05:40 <ajs[m]> ?
18:05:47 <suraeNoether> I expect about an hour before clsag is done
18:05:49 <ajs[m]> I thought it was just for me
18:05:50 <atoc> I noticed it disappeared too.
18:06:04 <sgp_> it's gone
18:06:07 <rehrar> lol
18:06:10 <rehrar> give me a sec
18:06:10 <suraeNoether> Hmm. Who was running it?
18:06:11 <sgp_> sorry for derailing, something to fix later
18:06:15 <suraeNoether> Oh
18:06:29 <suraeNoether> Moving along :) what about you, Sarang?
18:06:32 <sarang> Sure
18:06:37 <koe> for those who want to access logs later: https://monerologs.net
18:06:50 <ajs[m]> lol
18:06:57 <sarang> The Triptych preprint has been updated with new efficiency data and some minor typo corrections (IACR 2020/018)
18:07:06 * Isthmus checks in
18:07:11 <sarang> It will appear on monero-site as MR 1197
18:07:31 <sarang> The DLSAG paper is being revised for its publication in the FC 2020 proceedings
18:07:42 <sarang> and we're working on updating the security model for later journal submission
18:08:03 <sarang> I have a monero-site MR ready to go for the CLSAG updates (MR 1202) as soon as suraeNoether's review is complete
18:08:12 <sarang> (and I get it updated on IACR)
18:08:47 <sarang> I did some major overhauls on the curve libraries that I use for ed25519 and ed448 testing (for prototyping only; don't use them in production)
18:09:01 <sarang> That included porting them to a bunch of other research projects
18:09:24 <sarang> I also did some updates on my Lelantus code to fix some Fiat-Shamir transcript issues
18:09:31 <sarang> And that's about it
18:11:50 <sarang> Does anyone else have research to share?
18:12:04 <sarang> We can also have any questions as well
18:12:27 <atoc> Currently I have been just familiarizing myself with Monero Research
18:12:59 <atoc> I have read quite a bit of Zero to Monero, and I also looked at the bipartite matching project: https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching
18:13:58 <atoc> I did have some questions, but I can go through them later with surae perhaps?
18:14:11 <suraeNoether> Sure, now is fine with me too
18:14:20 <suraeNoether> It's on topic :P
18:14:30 <sarang> Sure, go ahead
18:15:25 <koe> speaking of ZtM, thanks to Articmine the dynamic fee section has been greatly elaborated; anyone curious about all the justifications and derivation and analysis can find it in the latest draft; all that remains before I can publish are multisigs, bulletproofs, and proofreading (each of which will take a long time admittedly)
18:15:26 <koe> https://www.pdf-archive.com/2020/01/15/zerotomoneroebookmaster-v1-0-17/zerotomoneroebookmaster-v1-0-17.pdf
18:15:47 <atoc> Ok cool, well can you briefly give a high level description of this project? From what I understand so far is that this project will be used for user analysis along with statistical models, but hearing an overview from in your words would be nice.
18:16:12 <rehrar> it's good to see ZtM getting the update :)
18:16:55 <suraeNoether> Gotcha okay so first think about the Monero blockchain using two columns. List all of the one-time output keys from coinbases and from other transactions on the left and list all ring signatures or if you like key images on the right-hand column
18:17:48 <suraeNoether> You can then go and draw edges between one time keys and ring signatures indicating ring membership. So if I publish a ring signature with ring members a b and c, my ring signature on the right would have edges connecting it to the outputs a, b, and c on the left
18:18:28 <suraeNoether> These are what I call red edges in my code, and I also indicate blue edges connecting ring signatures on the right with the new fresh transaction one time keys that are output from their respective transactions on the left
18:18:30 <sarang> koe: I asked this before, but how detailed are you looking to get with bulletproofs?
18:18:44 <sarang> I fear you may end up essentially rewriting their entire paper, with little benefit to the typical reader
18:19:14 <suraeNoether> So the Monero blockchain can be visualized as this two-colored bipartite graph with one-time keys on the left, ring signatures on the right, red edges indicating ring membership, and blue edges indicating output relationships
18:19:42 <Isthmus> Hey @koe I owe you an email. I have some protocol notes, but have just been super swamped.
18:19:45 <atoc> Cool cool, I
18:19:47 <Isthmus> I'll try to get the email out in the next few days
18:19:49 <atoc> I'm with you*
18:19:58 <scoobybejesus> i am sort of busy, but wanted to throw out a question (in other words, don't let this question interrupt the current line of talk).  a response anytime would be great, though
18:20:04 <scoobybejesus> I was thinking about how people complain about outputs getting locked up for 10 blocks.  Consequently one must send to themself a multi-out txn to prevent that from happening.  What if we made the standard tx 2-in and 3-out (2 change)?  And maybe set them to send to different accounts, so they take on independent/divergent decedent txn histories.  Was curious if MRL had thoughts/impressions
18:20:22 <Isthmus> I also got halfway through updating Big Bang paper, but then got distracted. Hoping to finish that this weekend or next.
18:20:31 * Isthmus ends update
18:20:52 <suraeNoether> The ground truth of the situation is that each ring signature has a ring member that is the true signer of the signature, so for every ring signature with a bunch of red edges leading to a bunch of one-time output keys, somebody who's trying to track transactions is trying to pick the true spender from these red edges
18:21:25 <suraeNoether> And this is called the matching problem in the graph theory world, sometimes also called the assignment problem, sometimes called the assigned marriage problem lol
18:21:27 * Isthmus is pondering scoobybejesus 's idea
18:21:57 <suraeNoether> So somebody who is trying to track transactions on the Monero blockchain is really trying to find a maximum matching on the Monero blockchain, linking signatures to true spenders
18:22:03 <sgp_> scoobybejesus: I'd rather find ways to reduce the lock time
18:22:39 <koe> no worries Isthmus :); sarang that's a valid concern and Im really not sure since I don't actually understand bulletproofs yet; I think if the bulletproofs paper is clear enough it will be fine to point people in that direction; I dislike the idea of leaving things open ended, but maybe it's just a useless hangup ^.^
18:22:40 <suraeNoether> The signatures themselves give nothing away about which edge is supposed to be the true spender, so without any additional information the attacker just has to guess, and so every possible maximum matching is equivalently good in this world
18:22:44 <atoc> Ah okay, I see. It seemed as if you were trying to find out if there was a way to trace back transactions.
18:22:57 <suraeNoether> I am kinda
18:23:28 <suraeNoether> So my graph theory python code allows you to build a graph, and then find maximum matchings, and if you wait the edges, it'll find the heaviest weight matching so that somebody using extra metadata can do better than just guessing at random
18:23:36 <suraeNoether> Weight*
18:24:04 <almutasim> How do you assign weights?
18:24:27 <suraeNoether> Right so that's outside of the scope of graph theory and in the scope of my simulations...
18:24:51 <almutasim> Ah. Are they probabilities?
18:24:55 <atoc> Is this where statistical models come into play/
18:25:41 <suraeNoether> Yep. The way that I'm trying to do this is I'm simulating an economy between Alice, Eve and exchange with KYC information, and Bob representing all background players in the Monero economy. I'm even telling Eve the information about the Markov chain from the beginning, which models eves perfect ability to learn your habits.
18:25:51 <suraeNoether> So this Eve is able to wait the graph using some null hypothesis about user behavior
18:26:09 <suraeNoether> once she does this, even though she doesn't know the ground truth reality of the blockchain, she can find a maximum likelihood estimate which corresponds to a maximum weight matching
18:26:14 <sarang> s/wait/weight/ ?
18:26:18 <suraeNoether> Weight* sorry I'm on voice to text
18:26:57 <suraeNoether> So the simulator simulates an economy, strips information out of the graph that Eve doesn't know, hands the blockchain to Eve, Eve weights the graph and compute some maximum likelihood estimate, and this maximum likelihood estimate is compared to the simulators ground truth
18:27:17 <suraeNoether> When things are working I get preliminary data that suggests that Eve is really really bad at this game Even though she's given perfect information about Alice's habits
18:27:35 <suraeNoether> But that's all preliminary because my code is only intermittently working and I am currently in the midst of refactoring it to be simpler.
18:27:36 <almutasim> That's encouraging.
18:28:46 <atoc> Quite interesting surae. I understood about half of it before, but given you're description I see the goal of the project now.
18:29:31 <atoc> In a way you are trying to see: given the current information can we figure who sent the transaction given previous user habits.
18:29:36 <derpy_bridge> [keybase] <surae>: These results are encouraging, but I want to emphasize that these are all preliminary results and are not at all trustworthy yet
18:31:16 <derpy_bridge> [keybase] <surae>: Atoc in particular I want to assess the goodness of these approaches that everybody has been using for linkability... I get the suspicion that the false positive rates are unacceptably high, but since previous papers like Monero link never properly constructed their experiments, they were never able to tease that out
18:32:07 <atoc> Have others ran linkability tests on Monero previously?
18:33:08 <derpy_bridge> [keybase] <surae>: Yes, monerolink was one of the first. that paper is actually the inspiration for using simulations in order to tease out various performance rates
18:33:29 <atoc> Good to know. I will take a look at that.
18:33:49 <derpy_bridge> [keybase] <surae>: I have a lot of respect for the people who contributed to the MoneroLink paper, and it made Monero a lot better despite the fact that it was perceived by our community as very adversarial... But, the paper did suffer from a couple of bad scientific design issues that made some of their claims more sensational than supported by the evidence
18:34:26 <atoc> Ah I see, was MoneroLink done by the Monero community or third-party?
18:34:41 <derpy_bridge> [keybase] <surae>: The fact that it was written by people who had a financial interest in succeeding compared to Monero was viewed as very suspicious by a lot of folks.
18:34:44 <koe> suraeNoether have you collected a list of tracability analysis papers? for example sarang mentioned a preprint earlier; or maybe Isthmus has that list
18:34:54 <derpy_bridge> [keybase] <surae>: Andrew Miller from Zcash and a couple of other folks who were involved with Zcash were authors
18:36:10 <derpy_bridge> [keybase] <surae>: Actually you know, Sarang may have a better list than I would... A paper came out last year describing a game not dissimilar from my graph theory game and they named it after sun tzu. But I can be more helpful in finding background papers. Basically any papers on the traceability of anonymous communication networks has some degree of applicability to the Monero blockchain
18:36:50 <derpy_bridge> [keybase] <surae>: "perfect matching disclosure attacks" is a general paper that was critical in the construction of the matching stuff
18:36:54 <atoc> I see I see. So I see a couple of todos listed (unity tests and another). What are some important priorities for this project? I feel I can contribute to this project as a start.
18:38:34 <atoc> Just a little background about myself: I'm an academic researcher in theoretical computer science (neural algorithms).
18:38:36 <derpy_bridge> [keybase] <surae>: Let's talk about that after the meeting
18:38:40 <atoc> sure
18:38:46 <MRL-discord> <Isthmus> Dang, I got bumped off IRC
18:38:51 <MRL-discord> <Isthmus> Can't log back in
18:38:56 <derpy_bridge> [keybase] <surae>: speaking of the meeting, isthmus tells me that he has lost access to IRC... And I also happened to lose access to IRC and I'm just using the keybase bridge
18:38:57 <MRL-discord> <Isthmus> *IRCcloud
18:39:16 <derpy_bridge> [keybase] <surae>: it looks to me like IRC cloud has gone down which means the vast majority of the people in this room are probably not here anymore
18:39:19 <MRL-discord> <Isthmus> @atoc nice to meet you, excited to contribute
18:39:25 <MRL-discord> <Isthmus> *to collaborate
18:39:32 <MRL-discord> <Isthmus> Sorry, I'm in a meatspace meeting too
18:39:51 <derpy_bridge> [keybase] <surae>: So we'll give it a few more minutes and if I receive cloud doesn't come back or if nobody else speaks up, I say we adjourn the meeting
18:39:58 <derpy_bridge> [keybase] <surae>: If irccloud*
18:40:14 <MRL-discord> <Isthmus> So I just realized that we aren't fully utilizing the archival network data. But I'll wait for our IRCcloud comrades to return
18:40:20 <xmrmatterbridge> <sgp_> yes, irccloud seems to be down for everyone
18:40:29 <derpy_bridge> [keybase] <surae>: I had a question for isthmus about the archival network and lock times
18:40:35 <MRL-discord> <Isthmus> sup
18:41:05 <derpy_bridge> [keybase] <surae>: I want to know the distribution of fork lengths observed so far, and I also want to know the distribution of forklengths experienced by a new node syncing
18:42:23 <atoc> isthmus nice to meet you as well.
18:44:41 <atoc> hmm okay and sorry what do you mean fork lengths?
18:45:33 <derpy_bridge> [keybase] <surae>: As in Nakamura consensus resolving a fork
18:45:40 <derpy_bridge> [keybase] <surae>: Nakamoto
18:45:51 <derpy_bridge> [keybase] <surae>: WTF that was autocorrect too not voice to text
18:46:51 <almutasim> It should be correcting the other way.
18:46:54 <atoc> I see, alright I will begin looking into this.
18:46:59 <derpy_bridge> [keybase] <surae>: Isthmus actually specifically I want an estimate of the parameter r under the null hypothesis that fork lengths are negbinom(p, r)
18:48:12 <derpy_bridge> [keybase] <surae>: I think lock time has to be proportional to r to protect most transactions from most rollbacks
18:48:47 <derpy_bridge> [keybase] <surae>: Okay since irccloud is now fartcloud, I say this meeting is adjourned.
18:49:07 <koe> good meeting! happy day to yall
18:49:16 <derpy_bridge> [keybase] <surae>: Good seeing you around koe
18:49:30 <xmrmatterbridge> <sgp_> thanks
18:49:43 <almutasim> Thanks. Good meeting.
18:49:47 <xmrmatterbridge> <sgp_> surae: meeting in #monero-konferenco starts shortly if you can come
18:49:57 <derpy_bridge> [keybase] <surae>: Omw
18:51:30 <derpy_bridge> [keybase] <surae>: Atoc the code you are looking at is suffering at least one big problem. Eve is not getting or not using all her kyc info appropriately when she weights and matches.
18:51:54 <derpy_bridge> [keybase] <surae>: And I believe someone of my unit tests for the simulator are failing
18:52:10 <atoc> Hmm I see.
18:52:41 <atoc> I will try looking at the unit tests again and see if I can get Eve to use all her info. What you mean not using it appropriately though?
18:52:58 <atoc> I may see it in the code, but incase I don't lol.
18:53:25 <derpy_bridge> [keybase] <surae>: The simulator writes the ledger to file correctly and in human readable format, and Eve also outputs her guesses in human readable format. But Eve is an idiot, forgetting her own transactions for example and assuming them to Alice or Bob
18:53:40 <derpy_bridge> [keybase] <surae>: There are also other stupid problems
18:54:11 <derpy_bridge> [keybase] <surae>: Since it's human readable, it's a little like solving a mystery. "Hmm now why did Eve think *that?*
18:54:38 <atoc> I see. Well should I try fixing these first or get the distribution of fork lengths?
18:55:00 <atoc> Also, does isthmus work on this project too? Or is it mainly you?
18:55:05 <derpy_bridge> [keybase] <surae>: Oh I think the fork lengths thing Isthmus can most easily help with
18:55:12 <derpy_bridge> [keybase] <surae>: That's separate
18:55:18 <atoc> Ah I see.
18:55:25 <derpy_bridge> [keybase] <surae>: Not directly related to matching
18:55:45 <derpy_bridge> [keybase] <surae>: I'm primary on matching
18:56:11 <atoc> Oh alright. Well then I can look into the other issues you mention and contribute further if there is other work left.
18:58:30 <derpy_bridge> [keybase] <surae>: My code is unnecessarily complicated, and I am in the midst of refactoring it into something much simpler... But that is actually probably an equivalently large task compared to debugging the current code base... So there's a decent chance that you actually beat me because the vast majority of the infrastructure is already written for your end of the project
18:59:14 <derpy_bridge> [keybase] <surae>: Look at me saying you're into the project like you've been sucked in already
18:59:50 <atoc> All good lol. I would like to be sucked into a project. I actually talked with Sarang first and he mentioned a couple other projects
19:00:00 <atoc> but this one seemed like it would best suit me.
19:00:25 <atoc> as I feel I can contribute a fair amount to it. I can also give hints on making it simpler once I go through it.
19:02:16 <derpy_bridge> [keybase] <surae>: Yeah, endogenic and I have had discussions about it already... My current refactoring is basically the current code base, but with the functions broken down into smaller and smaller fundamental pieces that are easier to individually test
19:03:39 <derpy_bridge> [keybase] <surae>: I may end up pushing to a new branch named plutonium later today. Could be that more hands during refactoring makes less work. Let me know how much of my code is more like spaghetti to you than code
19:04:16 <derpy_bridge> [keybase] <surae>: The simplification is small enough to fit on my whiteboard front and back which I alluded to earlier
19:04:36 <atoc> Will do. I will take a look at it later today and get you feedback.
19:04:41 <derpy_bridge> [keybase] <surae>: That sort of prompts me to just push what I have... Give me a few hours though cuz I need to finish clsag
19:04:55 <atoc> Sure no problem
19:05:24 <atoc> btw you can reach me at: at0c⊙pc (if I'm not here)
19:07:17 <atoc> note: the 0 is a zero not 'o'
19:49:23 <derpy_bridge> [keybase] <surae>: gotcha
19:49:36 <derpy_bridge> [keybase] <surae>: i'm surae.noether⊙pc or surae⊙go
20:18:04 <gingeropolous> what voice to text are you using?