Hey, everyone, I wanted to write up a 2-month update. As usual, I am seeking feedback and commentary from the community. I spent about half of my time this month reading papers and textbooks. Similarly to last month, I spend time in #monero-dev on freenode, leading to many productive conversations. We started swamping that room with discussion, though, so we started the newer #monero-research-lab chat to discuss stuff. Knaccc, luigi, moneromooo, and kenshi84 are throwing down lots and lots of crypto ideas in there. It's been highly productive. At the end of August I will release the first Monero newsletter as my “final update” for the 3-month period of June-August. My first order of business in September will be to revise and update the research road map and release MRL-R002.

My motivations in the past month have shifted enormously because of some security concerns with the EABE "attack" described by knaccc, as well as some of the security concerns presented in the paper by Miller et al and the paper by Kumar et al. So I'll discuss those first.

Criticisms by Miller and Kumar: These are serious papers, in the sense that I am taking them seriously. But I don't think there is a lot of cause for serious concern. Both papers confuse the problem of sensitivity vs. specificity of a test, and ignore the problem of the false positive paradox in favor of sensationalist-sounding results.

The Miller paper, from my reading, looks to make a certain assumption about non-deducible transactions based on the deducible set, then develops a decision rule based on that. Disregard for a moment that we have a minimum ring-size now, and thus the deducibility of transactions "damps out" over time as transactions ripple through the network. Note they don't bother testing whether the properties of non-deducible transactions correlate with the properties of the deducible set, because they can't test such hypotheses with non-deducible transactions.... they are non-deducible. So... to be clear... these guys develop a decision rule based on an unfalsifiable hypothesis (e.g. timing distribution between deducible transactions and undeducible transactions are similar, since the most recent signer of a deduced transaction is usually the one that is deduced to be the true signer, the most receng signer of an undeduced transaction is usually the signer, etc), then construct a monte carlo simulation based on that same unfalisfiable hypothesis, and then showed their decision rule did a good job with their MC simulation. Okay, so far I'm not seeing a security concern here.

The so-called distributional problem put forth by Miller is still interesting and concerning to me, but for non-crypto reasons. I will elaborate some time in the coming weeks on this.

The Kumar paper is a little bit better, I actually think somewhat highly of it. They actually bother to define their true positive sets, for example, and they actually try to justify their work, they seem to grasp the idea of sensitivity vs. specificity and that they can't quite nail down both with Monero. Unfortunately, most of the criticisms from the Kumar paper are no longer relevant (although they certainly were at one time) because now RingCT transactions obfuscate amounts. Some of the arguments are still valid in that paper. But those have a few subtle flaws to them... I can see how someone doing something similar to this paper could have a pretty strong impact, but the specific criticisms in that paper are somewhat weak. Having said that, a few ideas from that paper have helped me come up with models for the EABE stuff (see below). If I'm going to respond to either or both, it will probably only be the Kumar paper.

EABE, Churn, Min mix-ins, Blockchain compression: If very few transactions occur between two transaction outputs owned by a KYC exchange Eve, then Eve can leverage her KYC knowledge of the identities of her users as well as the one-time receiving addresses of her users to reduce the variance in her estimates of culpability in that chain of transactions. This is a very serious problem because many cryptocurrency users and merchants have the following habit: Alice sees shiny object on sale with Bob, Alice buys crypto from Eve to send to Bob to buy shiny object, Bob cashes out with Eve with no intervening transactions. In this scenario, when Alice makes regular purchases of shiny objects from Bob, Eve can establish a pattern of Alice's purchasing habits with Bob. The problem with EABE? Alice gave Eve her personal identity and allowed Eve to link it to certain one-time addresses of Alice's. Alice willfully, by using a KYC exchange, sacrificed the anonymity properties granted by stealth addresses. This isn't really a cryptography problem, it's a human behavior problem.

The current solution, churn, is essentially "let's leverage the privacy properties of Monero such that most users are sufficiently protected from exposure." In this case, protection from exposure means ensureing that most users are implicated in most transactions, up to some definition of most.

My first-order estimates for using a churn-based solution for EABE suggested that with a ring size of around 10, users can obfuscate their purchasing habits with at most 7 churns. Bigger ring size, fewer churns, but the effect is rather mild; you still need 6 churns with a ring size of something like 20. This computation is based solely on the pigeon-hole principle.

My second-order estimates were based on the hypergeometric distribution. These results suggest that as minimum ring sizes get bigger than 15-20, "most" old cryptonote transaction outputs are implicated in "most" new randomly fashioned transaction outputs. Formally: for any one known (KYC) user, for any one known (revealed) transaction output owned by that user, and for any new randomly fashioned transaction output, as ring sizes get larger and larger than 15-20, the probability that the revealed output is implicated somewhere in the history of the new randomly fashioned transaction output approaches 1.0 very quickly, up to some definition of quickly. I was startled by how rapidly the probability "snapped" to 1.0 as ring size increased.

Also, think about the expected number of steps backward we need to take, proceeding through the history of the new randomly fashioned transaction output, before we hit the known revealed transaction output. As the ring size gets big, this number of steps gets small (with a ring size equal to "all transaction outputs" this step size is guaranteed to be 1.)

So, this was all good news; it suggests that a larger minimum ring size will allow churning to have a maximal effect. And since the beefy part of our transactions right now are range proofs, not ring signatures, this seems like a not-so-bad solution. I'm working on a 3rd order estimate right now where an observer sees many transaction outputs bundled into transactions, many of which are bundled into blocks, which are observed over time. The goal is to select system parameters to get close to the "all transaction output" scenario without causing a huge blockchain bloat. Yet... yet, rather than putting effort into detailing a computational model to get precise security bounds on this particular mode of attack, though, it would be far better to set ring sizes to something absurdly large, say ring size = 300 or 3000, and just recommend to users they send funds to themselves once before using with a merchant.

Of course, in order to justify ring signatures that large (heck, in order to compute ring sigs that large), we need more efficient ring signatures. I have found at least one set-up for O(sqrt(N)) ring signatures that doesn't require a trusted set-up, but it uses pairings-based cryptography. I'm currently working on converting this to something more suitable for our purposes.

So, after all this effort, it turns out that the best way to protect against EABE is blockchain compression and making signatures and range proofs smaller. Consequently, this idea has taken up the vast majority of my time this past month. I have a few hot leads in that regard.

Recruitment: Sarang posted to the FFS, go take a look. Once coming on board, we will together take another deeper look at the MRL Research Road Map and come up with a more organized action plan. I recommend folks take a look at that funding thread, offer advice/criticism, throw some micronero that way if they are so inclined.

Paper repository: I'm considering the idea of getting a repository going of all the papers I've read (or at least skimmed) recently. I'm not sure on the copyright implications of gathering all those PDFs together on github. If anyone has any ideas or suggestions on that front, please let me know. I've skimmed over 100 papers, but I've read around 40 carefully.

Zero-Knowledge Lit Review: Due to some security issues regarding the EABE attack, churn, etc, I got distracted from working on this. I plan on finishing up my current round of edits for Jeffrey very soon.

RingCT: I have found a few promising papers on making range proofs smaller, and we have had some discussions about embedding more information in range proofs, like some encrypted messages and so on. I have a single paragraph written, somewhere, on the proofs in Shen's paper.

Threshold multisignatures and subaddresses: My contribution to this is temporarily on hold. Knaccc and kenshi are still working on subaddresses regularly. I'm going to be very careful about saying nothing more about this here.

Bitcoin with one time keys?

"From what I read, I didn't see anything about zk-research as it would apply to Monero." A few points. First, and most importantly, this is a first draft, and Jeffrey and I are working on a second draft as we speak that elaborates on usages of these constructions in cryptocurrency. Second, I didn't provide Jeffrey with any direction on this paper... leading me to... third, I got from him exactly what I had hoped: a broad-spectrum, shotgun-style look at the schemes as they are currently described and used. I wanted a broad-spectrum lit review of snarks to understand them in the abstract, to know how and when to use them in the future when I design cryptoschemes. Lastly, this was a lit review I was going to do for myself anyway, so it seemed wasteful to not document the process and give Jeffrey some more experience in technical writing.

I understand your concern about the papers criticizing Monero. These papers will be addressed directly with a research bulletin, hopefully by the end of my first three months with Monero. Right now I have literally only two MRL research bulletin drafts going: one of them is the EABE attack and one of them is a pair of responses to the recent criticisms. However in my estimation, although the criticisms are worth responding to, they do not present an immediate security risk. I have been devoting most of my time most recently to looking into the EABE attack and the churning approach to solving the problem, because this is a very serious route for an observer to de-anonymize folk's financial behavior that represents a security threat right now.

It's an interesting challenge to balance research into immediate issues that need resolving with long-term benefit to the currency.

1) Replacing possibly insecure schemes with provably secure schemes at a low cost is the motivation. In this instance, we have a particular scheme that is known to be implementation-sensitive and lacks a security proof. There is a relatively cheap alternative with an implementation-agnostic security proof. Seems like a no-brainer to not rely on the strength of any particular component (like Keccak) if we don't need to.

2) It is a literature review of snarks. It is about snarks because I was curious about how snarks worked and Jeffrey offered to do some work for me. Moreover, transaction validation, in an abstract sense, is "like" an argument of knowledge, and cryptographic primitives revolving around that idea are therefore of great interest to my research in cryptocurrencies. I don't know where it's going to be published yet, we haven't gotten that far into editing.

3) I am an algebraist but I have taken several graduate-level courses on cryptography and algebraic geometry underlying elliptic curve crypto. I'm currently working through the borromean ring signature stuff and the RingCT stuff.

4) RingCT proofs are big because of the range proofs; zk-proving that the amount of a transaction output is within a certain range. I have been first focusing on the signature changes in RingCT with an eye toward multisigs, so I haven't had the pleasure of figuring out the range proofs yet.

5) The only current description of the current multisig scheme, is here. The scheme requires vetting and a security proof before I'm going to be comfortable with it, although it's close to being implemented.

6) Let's say you work in law enforcement and you decide on a set of rules along the lines of "If we are more than 99% confident that so-and-so is implicated in a transaction, then we will consider this to be 'beyond a reasonable doubt.'" Then all anyone needs to do is hand-fashion their ring signatures to be in the 99.9th percentile. They will be excluded as an outlier at 99% confidence and be totally missed by law enforcement. On the other hand, if someone wants to frame you, they can hand-fashion their own ring signatures so that your outputs lie dead-smack-in-the-center of Mr. Law Enforcement's "best guess" window, although their outputs are in law enforcement's outlier regions.

Lying with statistics is super easy. Statistics all boils down to getting a "random" or a fair sample. In the real world, human behavior corrupts that immediately. Consequence of evolution/ecology/economics.

7) Forgive me, where are you quoting from? Which problem are you referring to here?

obviously I'm not OP, but one of the criticisms in the papers, that small 'mixin' sizes can affect the mixin sizes of others', without these people knowing that their anonymity set size has been reduced, actually isn't a problem for Monero anymore, even now. So was it just an announcement to this end that you were asking for? The problem was of the type 'if you send a transaction with two parties, and one of those is me, and then i send a transaction with that TXO, then obviously that one is me, and eliminating me from your anonymity set leaves just you. Now the minimum mixin size is 4, this just isn't an issue at all anymore.

Regarding the distribution issue, I completely agree -- OP this should absolutely be your focus for now. zk-snarks aren't at all relevant as they exist today, and I don't think anyone wants monero to turn into a zcash clone anyway. there are nice properties of monero (like total supply of coins being a publicly verifiable number) that would be lost if you were to implement zk-snarks. You should absolutely be looking at sublinear linkable ring signatures. They can be as small, or even smaller than snarks, and prover and verifier time are fast. But in the research roadmap you say that the distribution problem isn't a problem because monero has one time keys? This is a silly argument. the privacy of monero with the distribution problem and one time keys is ~the privacy of bitcoin with one time keys. that's not exactly what we're aiming for here, is it?

First of all, this is very exciting. To have the MRL officially back in action, at least for now, is outstanding. It's obvious that you are driven/motivated, intelligent, etc; and work done and related updates so far are very much appreciated. At the same time, I think it's important to play my role as a community member and also provide some [what is hopefully] constructive criticism.

-From what I read, I didn't see anything about zk-research as it would apply to Monero. In that respect, I'm a little disappointed. If something comes of it in the future, that could be exciting; but it actually doesn't seem pressing now.

-Yes, it would be great to see multisig formalized (if the fact that it isn't formalized is an issue). Certainly, an MRL paper describing Cryptonote design and implementation of N/N and (N-1)/N multisig would be awesome.

But here's the meat, IMO:

-Regarding the papers criticizing Monero, it would be nice to see this knocked out. If their arguments are flawed/slanted/etc, let's set the record straight. The papers are at least partially correct, so an MRL response may go a long way. I imagine that this response would be completed in connection with the churning/mandatory mixin issue and the distribution issue, which would be a huge, huge, huge accomplishment to have dealt with. In my view, these should be a primary focus. They all tie together, are all potentially critical to Monero's privacy claims.

Anyway, those are my two cents. Keep up the great work. I very much look forward to the next update.

One month update/statement of work! Seeking commentary and feedback from the community. I’ve spent most of my days in the past month in #monero-dev on freenode, leading to many productive conversations. I didn’t want to post my FFS for Sept-Nov until after I had updated the community. About 2 weeks ago, I posted the first MRL research roadmap. I’ll address those points more or less in order… after I first address a few things that will be making it onto the next MRL research roadmap. If you’ll notice, an enormous amount of my job is just to keep reading. That… probably won’t change much at least until September.

New stuff not on the last list

• I am in recruitment talks with PhD students who are graduating soon, looking for employment, and are interested in applying cryptography. We may have a post on the FFS in a few days from a recruit. These individuals are still on the job market in other areas, so even if these folks are fully funded, they may be offered a job somewhere else and turn down the position at Monero… in which case, if I understand the rules of the FFS appropriately, all the raised funds will go to the Monero general fund, I think. I need verification on that. Due to this strange set-up, we may want to discuss different strategies for hiring future researchers*.
• This could fall under the heading of “Future Proofing Monero” but it is a little shorter-term than that. After many conversations with members in #monero-dev and a few conversations with Sarang on my own time, it’s become clear that there is a prevalent “bad practice” in the Monero codebase inherited from CryptoNote: appending information to a message before hashing (one of many examples: one-time addresses are computed using H(rA || n)G + B, for example, where || denotes concatenation). This is considered a bad practice, using HMAC methods is considered superior and is the international standard for generating one-time codes (see here) Firstly, HMAC is provably secure. Secondly, there is at least one known attack against hashing concatenated messages while using weak hash functions. You may think to yourself “Ah, but we use Keccak, which is resistant against length extension attacks,” to which I respond “So? HMAC is provably secure and hashing concatenated messages is known to have at least one known attack vector.” For these reasons, I am recommending that every computation in the Monero codebase that uses hashed concatenated messages be updated to HMAC schemes. On the other hand, we could simply go through the code and identify every instance in the codebase in which we hash concatenated messages, consider the security requirements for that instance, and then determine whether it is necessary to switch to HMAC, but I don’t think that is more conservative in either the terms of time-to-implement or security.

Onto the actual MRLRRM.

1. Zero-Knowledge Lit Review: Today I uploaded the first draft of the literature review of zk-SNARKs written by Jeffrey Quesnelle. I have already provided comments back to him to gear the document more toward MRL goals, requests for clarification of material I’ve personally found confusing in the past in crypto, and so on; I expect that we will trade it back and forth a handful of more times. I am torn on whether to publish it as an MRL Research Bulletin, which is not formally peer-reviewed, or a peer-reviewed journal (I’m leaning toward that process). If there are any particular zk cryptoschemes that YOU know of that have been overlooked, let us know and we will do some more reading. The plan for this is still to shoot for publication (or at least submission) by early August.

2. RingCT: I have read the RingCT paper, mostly understand what is going on, and I am checking proofs and approaches thoroughly, looking for flaws that have not already been pointed out here. If anyone knows of more exploits, please let me know immediately. I am on the #monero-dev channel most of the time during the day, and I don’t want to miss anything. Still reading about Borromean ring sigs, range proofs, etc. I have not gotten far enough into this yet to put an expected time of completion on publication.

3. Other criticisms: I have not yet gotten to the two papers mentioned in the road map, but don’t worry too much. One of these papers makes some not-very-well-supported claims about how much of the blockchain that could be potentially revealed and somewhat disregards the one-time addresses, and one of these papers makes no assumptions about malicious users attempting to implicate ostensibly innocent users of criminal transactions. Both are serious papers, to be sure, but I am de-prioritizing them a little bit.

4. Threshold multisignatures: Currently reading. A lot. I have some concerns about how this was pushed into the testing phase already; normally it would be fine to push something like this even if it only comes with a brief, clearly written explanation of what is going on (think the cryptonote standards), not necessarily with security proofs or peer-reviewed vetting… but we don’t even really have a short standard written up, afaik, just an old blog post by Shen and a half-written MRL Research Bulletin.

5. Churning, mandatory mix-ins: I’ve thought a lot about this problem presented by knaccc of an exchange, Eve, determining the purchase habits of Alice at Bob’s Burgers. No solutions yet except churning, but this has probably been what I’ve spent the most time thinking about.

6. Signature sizes, RingCT: Add to this list “range proof sizes.” No progress to report yet beyond reading.

7. The Distributional Problem: I think game-theory can allow us to get around this without too much difficulty, but I have nothing formally composed yet. I’m thinking about the game of bombers and fighters: an attacker gets to send a squadron of planes against a defender. The defender can either target fighters, which are lightly shielded, or bombers, which are heavily shielded; the attacker can place bombs on either the fighters or the bombers. If the bombs get through, the attacker wins and gets a point, otherwise the defender wins and gets a point. The game is repeatedly played for a number of rounds. What strategy on the part of each player optimizes their chance of success? It turns out the solution is usually “the most random strategy,” which is to say, the least predictable one.

Oh, on point 9 from the MRL-R001: Hardness of blockchain analysis: I have some ideas on how to prove the equivalence of this problem with certain NP or NP-Hard problems, but I haven’t put a lot of formal energy into it except I have a document in which I formally state a model problem with similar properties. I’m convinced that the hardness is astronomical, but I have not written anything up.

I have made no progress on points 8 or 10-13 beyond some thought. These are all rather low priority right now anyhow. I will make an update like this at the end of next month as well here on the forums, and at the end of August I will release the first Monero newsletter as my “final update” for the 3-month period of June-August. My first order of business in September will be to revise and update the research road map and release MRL-R002.

*What I’m thinking about is one- or two-year “appointment” or “visiting researcher” positions, one or two at a time, where these researchers are paid out of a common research fund. Given the volatility of cryptocurrency and given how the FFS typically funds projects over rather short spans of time, this is an interesting challenge; I’m inclined to just let folks who are interested apply on their own through the FFS the way I did, but that is a barrier toward recruitment. I have more urgent things on my mind right now, but this has been percolating. I will probably make a recommendation about this by the end of my first 3-month pay period, and I will probably just throw my hands up and discard the idea by the end of the year.

In regards to your comment about ring signatures: the ring sig implementation in the cryptonote reference was, indeed, a non-interactive zk proof.

Hey everyone! I wanted to write a quick post to thank everyone again for funding me, and to provide a quick update on my progress.

Everyone seemed rather keen on the idea of a newsletter/research roadmap, so at the end of each 3-month period, I'm going to write up a little newsletter with a picture of where we've been, where we are, and where we are going. But since I just began, I figured that I should write up a brief initial description of the topics that will be under investigation in the first 3 months. This way, the community doesn't need to wait 3 full months to see what I'm getting up to. Here is the first MRL Research Roadmap. Expect another at the end of August.

In this case, it's little more than a to-do list ranked roughly by urgency and timeline: urgent or short projects come first on the list, non-urgent or longer-term projects occur later in the list. Future research roadmaps will include details on the progress of each of these items, will have new items added to it, old items removed, and so on. I'm seeking feedback for this roadmap. If someone has a pet project, or a suspected security flaw, we should reshuffle the list around as appropriate.

The first item on the list is not really a to-do but a brag, as it is a rather exciting development. A graduate student in computer science named Jeffrey Quesnelle at the University of Michigan-Dearborne has contacted MRL and is interested in dabbling with cryptocurrencies for his thesis! He has already written a literature review for me on the history of ZK-SNARKs, related constructions, and how they relate to cryptocurrencies. We will be whipping this into shape for a peer review publication by the end of my first 3-month period with MRL at the latest (first round of copy-editing is almost complete, just waiting on me to finish up a few pages of notes). Jeffrey is willing to do work on behalf of MRL like prototyping new cryptosystems. His experience includes cryptography in vehicles for the automotive industry and has interests regarding the internet-of-things, so if anyone has any other tasks for Jeffrey, we can always put him through the ringer :D

You will notice this roadmap covers a lot of ground, from immediate small projects to pie-in-the-sky future-proofing. None of this is guaranteed, and some of these projects could take years, even with many many contributors, so do not consider this a list of things that will be coming to Monero soon (although some high-urgency, short-term projects will be seeing something rather soon by necessity). These are essentially the big buckets I'm currently putting my efforts into. Again, I'm seeking feedback, please do not hesitate to contact me.

> Ring signatures actually are zero-knowledge proofs. I think, technically, they're something like witness indistinguishable (non-interactive) zero-knowledge proofs of membership?

My understanding is that there exists zero-knowledge implementations of ring signatures but not every implementation of ring signatures are zero-knowledge. AFAIK anyway. If you have a link, I'd read it.

> I don't hugely understand what you meant by > any system built without zero-knowledge protocols is leaking info, but I guess you're concerned about metadata? This is actually a topic I've wanted to do a big collection of info on for a while: What is even revealing about Monero transactions at this point? Timing analysis?

Fact of the matter is unless a protocol is provably zero knowledge (either perfectly zero knowledge or statistically zero knowledge) then a non-trivial amount of information is made available by definition (otherwise you could have proven your protocol was zk in the first place). You or I may not be clever enough to figure out how to piece that information together, but someone might be clever enough, or an advanced machine learning algorithm crawling the Monero blockchain may be clever enough in a few years.

Timing is included in this. It may seem like a trivial issue, but if you can pin a transaction down to within +/- 2 minutes using block height, you have quite a bit of knowledge of that transaction. It makes the knacccattack (churning) particularly effective: not only can an exchange determine the purchasing habits of its customers, it can determine what time of night they prefer to buy their hentai pillows with monero.

> 'Intersection sets' (where a given sender and recipient appear together more often than expected) are an often cited issue with 'mixing' schemes, but actually don't affect monero (as address/public key reuse is impossss) so you can emphasize that somewhere.

Intersection sets are interesting. So are techniques for solving nonograms and sudoku. I fear the day that Grobner bases can be brought to bear against a blockchain, even one that uses one-time addresses.

>Are the attacks outlined in AM's monerolink inherent to passive mixing schemes? Is the distribution that transactions get picked from fixed now?

I don't know yet, but that paper is on the top of my todo. AFAIK the distribution is still triangular, but "fixed" implies there is something wrong with our current method. FWIW, there is a game-theoretic thing happening, where if an eavesdropper assumes that transactions follow some "true" distribution, a malicious user could use that assumption to convince the eavesdropper that another ring member was responsible for a transaction: simply select an innocent and unaware ring member that is an outlier with respect to the assumed distribution.

> Are these sort of 'what people do in the future can directly influence the anonymity that I, following the protocol exactly, can get' problems inherent in passive mixing protocols?

This is not something I have considered, and the answer would be highly dependent on the definition of the passive mixing protocol and the specific implementation.

Keep in mind, though, Cryptonote/monero isn't really a mixing protocol, passive or otherwise, because there is a probabilistic thing happening. In a mixing protocol (say an old school vanilla bitcoin tumbler, not a shapeshift) you are playing a big pea-and-cup game, but an observer can watch every move carefully and, after a sufficiently long (possibly very long) period of time of computation, the observer can determine where each little pea ended up. Mixing protocols are deterministic in that sense. In Cryptonote, implication of ownership is shared across multiple addresses (all of which are one-time addresses, no less).

Even knowing deterministically where the vast majority of the money is going is not enough to pin down the probabilistic ownership thing. If I work for the NSA and I have already revealed a million transactions in the mempool, and one of the owners of one of those transactions signs a ring with even only ONE other member, I will not be able to do better than a coin flip in guessing the signer without extra information. This is distinctly different from deterministic mixing: if I have a bunch of bitcoin UTXOs and I send them through a mixer, no matter how large, I will be able to eventually determine exactly which addresses ended up with those UTXOs. In fact, for each and every little transaction I create to mix them all up, I can see the sender and receiver addresses clearly.

One question might be "can traditional mixers outpace blockchain forensics," but that's a completely different topic (and one I haven't thought about.

>How do we define them? How do we minimise the damage? How do we parametrise the leakage?

Good question. I think, short of perfectly zero knowledge constructions, there will always be a trade-off making your security dependent upon future (possibly malicious) user behavior.

>Quantum proofing: what do you actually want to do here? This might be trivial from both a stealth address and pedersen commitment PoV; less so from a ring signature perspective. But that would be a really cool research avenue (is it possible??? Do you have any quantum crypto friends??? I would super work on this :D).

Secretly I want Monero to be the first quantum-proof cyptocurrency: signatures, hashing algorithm, proof of work. Publicly, I have sincere doubts if PQC will ever be lightweight enough to build a decentralized blockchain that is remotely reasonably sized. All my crypto friends, quantum or otherwise, with a few exceptions, work at NSA or have zero interest in currency, unfortunately.

> You can easily make addresses much shorter.

Do tell.

> There are ways that you won't even have to communicate a new 'public viewing key' alongside every transaction. This reduces address size even more! (but only works for parties who have transacted with one another before

I will try to look into this, the notion of view keys has interested me a lot. I would love the ability to generate view keys with scaled viewing rights (viewing receipt of transactions, viewing sent transactions, viewing both, viewing transactions sent to or received from certain parties who consent somehow,

> Sublinear ring signatures! A lot of these (actually, all that I can find!?) depend on a CRS (I've been told off for this, but i'm using CRS here to mean common reference string. This is the reason for ZCash's trusted setup -- pretty much there are some very_necessary_parameters that can only be constructed with knowledge of very_dangerous_information). There's a result that NIZKs are impossible in the standard model, so choices are the above, or use the random oracle model (as monero does now!)

That is mostly my understanding also, and trusted setups need to be avoided in Monero, which is why I'm looking deeply into ring sigs, their history, their variations.

> block size is proportional to key size and key size is proportional to privacy. What does this mean? Do you mean signature size is proportional to ring size? Or do you mean security is proportional to key size? If it's the former, absolutely - sublinear ring signatures !! If it's the latter, I don't recommend making the system less secure as a way to reduce bloat!!!!

1) Block size is proportional to key size: I mean if you double the size of keys, you will double the average block size.

2) Key size is proportional to privacy: To encrypt any amount of information with perfect secrecy requires a key with the same "size" as that information. I mean this quite literally and abstractly: the more information you wish to encrypt, the larger the keys necessary to keep that information perfectly secret. I'm not saying we should reduce security to improve bloat, I am merely recognizing the trade-off between the two.

You are not wrong... there are a few points here, though, that I think are important. First and most simply, MRL is not the core team. If I make terrible recommendations, the core team can (AND SHOULD) ignore me. Examples of everyone ignoring me at will: (1) if the core team and community thinks I shouldn't seek external grants, then that should be removed from my job description, (2) even if we get MRL funded externally, MRL is not obligated to take the money (i.e. I'd rather apply and turn it down than not apply and never have the chance to turn it down) and (3) even if we accept external funding for MRL, the core team is under no obligation to listen to my results.

Secondly, and long-windedly, let me explain why I even inserted the idea into my first post. There's this problem I have with grant-based systems. A lot of STEM disciplines out there are grant-based; engineering, chemistry, etc. You publish or you perish, and you get grants or you perish. It's just the way of the research world in certain corners, especially education. This isn't entirely for bad reasons; offloading the cost of research away from the students and toward external sources makes paying for professors easier, and therefore makes education cheaper (imagine how much universities would charge if they were footing the bill for big physics projects instead of the Department of Energy...)

Until relatively recently, the math world hasn't exactly been considered a grant-based discipline. Computational mathematics has always required lots of funding for resources, but an algebraist or a topologist, historically, could do their work in a field of posies with a pen and paper. But recent trends in education has put pressure on math departments in many US universities to start seeking grants and funding (and so you start seeing a lot fewer pure mathematicians and a lot more computational mathematicians filling up departments, because provosts and deans put pressure on departments to hire professors who get grants... and because we need more computational research in a world where computers are increasingly dominating our lives). Consequently, almost every project pitches and applications in academia need to come equipped with four parts: (i) how will this help research? (ii) how will this help students? (iii) how will this serve the department/school/committee administratively? (iv) how will this help you get a grant?

Areas in math that are computational, or algorithmic, or related to simulations, or related to solving real-world logistic problems and optimization, these are areas that get grants because the ideas can be applied immediately and we see benefit immediately. An area like cryptocurrency has an astonishingly higher chance of getting grants than an area like commutative algebra, topology, or category theory. These areas are significantly less likely to get a grant because the applications of those extremely "pure" areas of math can take hundreds of years to crystallize. Sometimes that's not the case. Topology swept the Nobel prizes last year in physics. But my general point remains, which is the problem I have with grant-based systems, which is this.

My honest-to-god opinion? If this was a completely ideal world, I would completely agree with you. Personally, I think that expecting a mathematically-driven research group to become self-funded, while an admirable goal for any research group, is bad for a bunch of reasons. It's unlikely to be fruitful because grants in math are rare in the first place, it monetizes research, it takes away time from research, and overall, I didn't get into math research because I like writing grants. I don't like that our society has pushed math research in that direction. Your wariness is important. If some US government intelligence agency gives us a grant and MRL subsequently makes a proposal for a new signature scheme (or something), it would be reasonable for the community to be concerned about a repeat of the dual elliptic curve controversy involving the NSA from years ago.

Having said all that... the basic idea of alleviating the burden of funding research from the community, I think, is still a good one. And even though I'm not a fan of writing grants, and even though I don't think anyone here would be totally comfortable (if AT ALL comfortable) accepting an NSA grant... what if the granting agency is the National Science Foundation? Or some program through MIT's various cryptocurrency projects? I'm not convinced the idea of external funding is a good idea... but neither am I convinced it is a bad idea. And...

As I said earlier... I would rather apply and turn the money down than not apply. Then again... I may be the sort of guy who asked two girls out to prom in school so I'd have the option...

Hi, Brandon, welcome back.

In addition to this, one of my long-term goals for MRL is for the lab to be self-sufficient to remove the burden from the community members. Finding external sources of funding (possibly through grants, possibly through other sources) will likely be an annual tradition with an eye toward that goal.

With those actions come a shifting of power and influence. I think such actions should not be taken lightly.