I have read virtually everything surae has written on IRC at #monero-reasearch-lab as well as all the other monero IRC channels. I watched and heard him speak at the NYC Monero meetup this past May. I have no doubt about either his abilities or motivation.

Sarang has worked with the MRL in the past and I certainly hope he will be able to put greater time and effort into improving the very core of Monero.

I have helped fund surae and I am looking forward to doing my small part in funding Sarang and the MRL.

Sarang here. I just wanted to chime in and let the community know that I have been reading the excellent comments posted here so far. I apologize for not staying more engaged since posting this, but I've been in China teaching a packed three-week cryptology course. The time difference and crazy workload have been eating up all my time recently. I want to address a few of the comments in one fell swoop, if I may.

As to the rate, what was posted about contractor rates in general is very true. Making contract work a full-time position often commands rates that appear higher than for an equivalent employee position, due to things like insurance and other taxes. But regardless of the reason, we should all be comfortable with the amounts that researchers are paid, and it's definitely a good idea to have a discussion about something like standard rates as we move forward. My request is for an amount that I consider reasonable given my education and background, and I'm open to talking about it openly. But keep in mind that I would like to make this research position my full-time commitment during the contract period, and that would require fair pay for that level of commitment.

To address a related comment about the commitment, I would not have other university employment during this contract work. My university teaching positions are for summers only (like the course I'm teaching right now) and would end prior to accepting any funding. Again, I want this to be a full-time position, and will treat it as such.

The comments about deliverables are excellent, and make good points about the tightrope walk of good research. You don't want to fall into the trap of defining your projects so narrowly that you can't reasonably get any results, but also want to avoid being so broad as to avoid any real focus. Surae and I have been discussing the earlier [https://forum.getmonero.org/9/work-in-progress/87652/hire-phd-mathematician-to-look-into-post-quantum-crypto-zk-protocols-blockchain-bloat?page=&noscroll=1#post-91208](research roadmap), which is chock full of problems to address. Some are going to be more straightforward, while others are necessarily less defined. Open and regular communication with the community will be the name of the game throughout the process, if that helps to alleviate some of the concerns that were brought up.

I'll be finishing up the administrivia associated with the last few days of my course this week, but I'll hop on this thread as I'm able, to talk through any other thoughts or concerns with all of you. Thanks for your patience with my crazy schedule this month!

It's been my pleasure to start work for the Monero Research Lab as a full-time researcher under a Forum Funding System proposal. This month has seen a flurry of activity regarding new and innovative research to benefit Monero.

My initial area of work has been in sublinear ring signatures that integrate confidential transactions. The existing ring signatures, known as MLSAG signatures, scale linearly in size with the number of public keys in the obfuscation ring, but verification times are close to optimal with this approach. The inclusion of amount commitments in the scheme does add assurances of the privacy of transaction amounts, but increased privacy of the sender requires correspondingly larger ring sizes. The goal was to investigate signature schemes to replace MLSAG that scale sublinearly with the ring size. A solution, now dubbed StringCT in an admittedly poor attempt to integrate the initials of its designers, allows for confidential transactions while scaling logarithmically in size with the number of keys in the ring. I and the team verified the correctness of the scheme and produced (thanks to knaccc) a working implementation in code. This showed that while signature size is reduced and scales well to very large rings (which benefits sender privacy and reduces bloat), this comes at the cost of increased verification times (which may hinder adoption and widespread use). I will continue to work on optimizations to StringCT, alternative sublinear schemes that may provide better verification times, and any wild new cryptographic approaches to signatures.

I have also put work into proper and correct implementations of subaddresses. While Monero users have always enjoyed the benefit of recipient anonymity through the use of one-time output keys, maintenance of multiple wallets has been a source of inefficiency. A user may want to publish separate wallet addresses to prevent linking of funding destinations, but this currently requires that she scan each transaction once per wallet to determine if the transaction is destined for one of her wallets. A pull request was made on a solution, presented by kenshi84 and others in a pull request. Using a single master wallet, a user can generate as many subaddresses as he wishes, and publish them separately. Transactions destined for a subaddress still enjoy the privacy benefits of one-time keys. The user only has to maintain a small table of local information to keep track of subaddresses, which cannot be linked to each other or to the master wallet. Further, the user only needs to scan an incoming transaction once to efficiently determine which subaddress, if any, is the destination. The scheme allows for multiple outputs, though at the small cost of an additional transaction public key per output. A whitepaper documenting the scheme has been drafted and is forthcoming after the usual review process.

Less tangible, but still important, work continues to happen through the Lab's communication channels on IRC. Topics we discuss are often information gathering and planning that finds its way into the codebase or other papers. Discussions included debating fee structures and algorithms (which may see recommendations before the next hard fork), how to address the fate of proof-of-work under the assumption of ASIC developments (in the early stages, with much more research to follow), the balance of ring size versus computational effort (and how this affects churn), and a host of other topics related to Monero's plumbing. I and the other Lab researchers are regularly available for discussions of any issues that arise, and will continue this open approach to our research and development efforts. Expect to see these types of things on the next roadmap as our goals for them become more concrete and better understood in detail.

Finally, my spare time has been dedicated to the usual reading, study, and literature review that are the blessing and curse of any researcher. I always work to stay abreast of new developments in cryptography and security, and this month has been no exception. This has involved developments in signature schemes, commitment schemes (I am not afraid of commitment), proofs of work and space and stake and secure erasure, bilinear mapping applications to aggregate signatures, and many others. While not every new paper has applications to Monero, an important part of my role in the Lab is to consider the future of Monero from all sides by taking a broad look at cryptographic developments. This dedication to academic research continues to set Monero apart.

I look forward to continuing with work as documented on our recent roadmap, which I won't reiterate on this post in the interest of space. As stated in the initial proposal, I am extremely grateful to the community for its support of my contributions to the Lab. This support is essential for the ongoing academic research that sets Monero apart in the cryptocurrency world, and I'm excited to continue work each day to the benefit of the project.

Sarang here. After discussions and many engaging comments and suggestions on this forum, the subreddit, and on IRC, the proposal has been updated.

I support this proposal and vote for it to be moved to funding required. The comments from Sarang below satisfy me and hopefully those that raised questions:

> My request is for an amount that I consider reasonable given my education and background, and I'm open to talking about it openly. But keep in mind that I would like to make this research position my full-time commitment during the contract period, and that would require fair pay for that level of commitment.

>You don't want to fall into the trap of defining your projects so narrowly that you can't reasonably get any results, but also want to avoid being so broad as to avoid any real focus. Surae and I have been discussing the earlier [https://forum.getmonero.org/9/work-in-progress/87652/hire-phd-mathematician-to-look-into-post-quantum-crypto-zk-protocols-blockchain-bloat?page=&noscroll=1#post-91208](research roadmap), which is chock full of problems to address. Some are going to be more straightforward, while others are necessarily less defined. Open and regular communication with the community will be the name of the game throughout the process

I want to see this funded ASAP and hope that more academics take notice making recruiting to expand MRL easier in the future.

Sarang Noether here again, with the last of three monthly reports for my current funding period. As always, it's been a flurry of exciting activity and developments in Moneroland, and I'm pleased to present this summary of my work for November.

The beginning of the month was spent on a couple of big whitepapers that were being vetted for the project. The first was SPECTRE, a new technique for managing peer consensus. It should come as no surprise that we currently use a chain structure for managing block evolution, and apply simple longest-chain consensus to determine which of multiple competing chains a node should accept. The SPECTRE protocol does away with a single chain altogether in favor of a more general structure called a directed acyclic graph. In some ways, this simplifies the addition of multiple blocks, since order properties are changed. Correspondingly, the consensus algorithm is changed significantly. Instead of nodes voting based on longest chains, the blocks of the graph themselves vote on the order of other block pairs using the graph topology and ordering properties. It gets a little hairy to write down, but the security and scaling benefits can be significant. Throughput can climb without the corresponding hit on security that longest-chain consensus suffers. There are, however, issues that arose that could make pruning challenging. I and the rest of the Lab continue to keep our mathematical eyes open for further developments in this area.

Still on the topic of the blockchain/blockgraph, I performed an analysis of another construction, non-interactive proofs of proof-of-work (NIPoPoWs). Currently, a new node that comes online must request and validate the entire blockchain before it can be securely assured of the correctness of recent blocks it receives. If the node came online to watch transactions to a new wallet, it may be a substantial time before it can receive and spend funds reliably. With a NIPoPoW construction, a "diet node" can instead request a much smaller modified blockchain structure from a peer node that includes a short tail of recent blocks. To ensure that the diet node can trust these blocks, it also requests a supporting subset of historical blocks that include extra header data linking them to each other. The statistics behind these block headers allow the diet node to review competing supporting data from multiple peers and easily determine which to accept. The benefit is that the supporting block subset grows only logarithmically with the total size of the blockchain, so the diet node can much more quickly receive and send funds with new wallets whose transactions are only in the tail of the blockchain. There are shortcomings in that the diet node cannot use funds from blocks outside of the tail until it actually receives them in full; however, a NIPoPoW construction could be used to securely bootstrap new nodes until they receive the complete blockchain, helping to create a faster and smoother experience for new users. This work is ongoing.

The biggest new development, and the one that has received perhaps the most discussion in the cryptocurrency community, is in the topic of range proofs. Range proofs are used in Monero to support confidential transactions and prove that hidden amounts lie within a mathematically acceptable range to prevent certain attacks. However, our current construction uses a substantial amount of space and scales linearly with both the size of the range and the number of outputs in a transaction. A new whitepaper introduced bulletproofs, an alternative construction. Instead of using ring signatures on individual bits of the hidden amount, bulletproofs use a clever polynomial inner product protocol. The benefits for transaction size are significant, since the size of a bulletproof scales only logarithmically with both the size of the range and number of outputs. For a single-output transaction, it reduces the size of the range proof to around a tenth of its current size. For a two-output transaction, the savings are even greater. Unlike many other approaches where size and complexity battle it out, bulletproofs are efficient at verification, depending on optimizations to certain elliptic curve operations that are under investigation. I produced and tested a working Java implementation of linear bulletproofs (an initial simplification by the authors) and logarithmic bulletproofs to demonstrate correctness. Work is ongoing to optimize the logarithmic extension of the code, complete the verification complexity study, and implement efficient bulletproofs in the Monero codebase if so desired.

Finally, I and others in the Lab have discussed at length the importance of educational outreach. The cryptocurrency space continues to grow by leaps and bounds, but few students have the opportunity to study it. Cryptocurrencies like Monero are a unique blend of pure cryptography, mathematics of all sorts, clever computer science, and a bit of economics. Engaging new generations of students will help drive cryptocurrencies into the mainstream, which can benefit many different projects like Monero. There are opportunities for our researchers (including me) to conduct short courses of our own design on cryptocurrencies and distributed ledger technologies. I remain in active discussion with several academic organizations to plan such courses, the first of which may occur as early as next summer. It's been the consensus of the community that student outreach is an excellent investment in the future of our technology, and it highlights the fact that Monero supporters want to give back to society in productive ways.

This report ends my current funding period. I am eager and excited to continue work on new developments through March 2018, the work period for the round of funding that was recently completed. My deepest thanks and appreciation are extended to everyone who has offered support! The goodwill and support of the community continue to help the Monero Research Lab bring new and cutting-edge research to the table, now and in the future.

Stay classy!

Just chiming in that this is, in fact, Sarang. I invited him to apply a few weeks ago.

Sarang here again. After #monero-ffs discussions (moved from #monero-research-lab for clarity and sanity), the amount was updated to reflect a smoothing of recent price fluctuations. Comments and suggestions welcome, as always.

Absolutely! This is great news :D

Donated.

MRL is one of the reasons Monero is the most advanced cryptocurrency and improved massively over cryptonote, I absolutely support the idea.

10 XMR donated on behalf of muff1nman.

I am rehrar, and I approve this message.

Donated! Welcome aboard Sarang!

"complete trust in both the underlying mathematics and its implementation" This!!