Please login or register.

Hire mathematician (and computational physicist) to join res[...]

The What

Hi there! You should hire me, Sarang Noether, as a mathematical and cryptographic researcher to keep Monero stable and help it grow long term. I have a strong background in cryptography, data modeling, computational physics, and theoretical mathematics, as well as experience working with the Monero team. My good friend Surae Noether (now identified as masked mathematician Brandon Goodell) of the Monero Research Lab (MRL) team encouraged me to come on board as a full-time researcher.

The Who

Back in the day, I worked on interesting problems for MRL as it was starting to blossom as an integral part of the Monero project. Our team worked pseudonymously and analyzed existing constructions within the Monero standards while working out future improvements and analysis. You may remember me from IRC or the MRL papers. I completed separate M.S. degrees in mathematics and physics, and am set to defend my Ph.D. thesis in computational physics shortly.

My research background blends the dark side of mathematics with the messy side of material science. I use a lot of different numerical and simulation techniques to study how materials degrade, which involves huge data sets and plenty of custom analysis. My analysis is done using custom code in C++ and Python, but I have experiencing coding in ASP, C, Java, JavaScript, Perl, PHP, and other languages. To make a long story longer and toot my own horn a little: I am very good at applying rigorous mathematical and statistical analysis to big and ugly data. Before graduate school, I worked for the United States government (at the Naval Observatory in Washington) on the atomic clocks that power the GPS system, which involved a whole lotta time series analysis and more clock math than you can shake a wristwatch at. Ask me about leap seconds if you're bored sometime. I also developed and manage the cloud data infrastructure that powers the operational analysis tools for a good chunk of the bikeshare systems in the United States. If you've ever rented a bike in this country, there's a good chance it used code that I wrote.

On the side, I teach. I run cryptology courses for the Duke University Talent Identification Program and Johns Hopkins Center for Talented Youth in the United States and overseas, where I introduce gifted students to the awesome and terrifying world of ciphers. I've even given lectures on Monero and some of its notable constructions like ring signatures in my classes. Aside from this course, I write and deliver courses on algorithm design and scientific computing. I use these courses as an opportunity to stay sharp on the cutting edge of modern cryptography and hone my skills as a technical communicator.

The Why

Why should you support me? I have a history of work with Monero's development and a sharp eye for implementations of mathematical algorithms. Monero has a lot of talented community members specialized in fields like mathematics, applied cryptography, and computer science. What's rarer, though, is someone who has a strong background in all of them. I can look at a construction and proof of security and compare it to what's actually in code. Surae and I consult frequently on issues that the community brings up, new proposals for Monero's future, and independent reviews of existing code. We've caught some less-than-ideal implementations of primitives recently, like nonstandard input concatenation hashes that aren't provably secure and should probably go away. The recent research roadmap (say that five times fast) posted by Surae to the forums is ambitious, and rightly so. Monero has come a long way, but its growth means a larger footprint to keep an eye on, and more exciting developments to thoroughly and formally investigate.

The Proposal

I propose the community hire me for 467 XMR for a three-month period (starting from the full funding date) to conduct applied and theoretical research that falls in line with the priorities set forth in the research roadmap. Big-ticket items that are the target of my focus are:

  • Thorough analysis of ring signature proposals and signature bloat. We've seen a lot of recent activity in this area that needs attention. The current goal is to hit reliable sublinear signatures without a trusted setup.
  • Investiation of efficient "future-proofing" proposals. We are interested in nailing down some bilinear pairing constructions, zero-knowledge schemes, threshold signatures, and the like. A broader, but related, goal is to gain a complete understanding of what a post-quantum Monero looks like.
  • Community consensus projects. We get papers and proposals submitted all the time that don't necessarily fit neatly into our bulleted lists of research goals, but that deserve attention. When the community agrees that a new attack or construction needs expert eyes, that becomes a focal point.

Milestones for the ambitious research roadmap put forth by Surae are necessarily fluid and must adapt to the community's needs, but you should expect the following:

  • Executive summaries and whitepapers. These are best done collaboratively, and likely will be. We've done an excellent job of putting out thorough research bulletins, but the bar of technical expertise needed for a complete understanding is sometimes set a little too high. I want to see a bigger focus on general, but factually complete, summaries that are suitable for less-technical audiences within the community.
  • Community engagement. Expect my attention on IRC and the subreddit, where the action takes place. I like the idea of designated "office hours" dedicated to technical questions.
  • Researcher collaboration. One of the biggest reasons that I am interested in this transition to full-time research is a desire to increase Monero's research footprint collaboratively. Surae and I have a history of productive mathematical work together, both within Monero and without. Internal conversations don't always happen in public, but are a major part of research in any field. Of course, at the end of the three-month period, the community should review my work and recommend (either for or against) a renewal of the proposal.

What do I want to accomplish? I want to grow the MRL program as a full-time member of the team. Monero succeeds when its community has complete trust in both the underlying mathematics and its implementation, and hiring strong researchers demonstrates to the world that Monero is serious, stable, and here for the long haul. The roadmaps include ambitious but reasonable plans to reduce blockchain bloat, continue to check under the rug for existing implementation issues, study constructions like ring signature mix-ins, and ensure Monero will remain safe and reliable in a post-quantum world. I've enjoyed consulting for MRL already, both in the past as a part-time paid researcher and more recently as a volunteer. But the team and community benefit from mathematicians who can devote their full attention to the project. The community's recent show of support to Surae was a good move that confirmed the community places a high value on strong research. The best time to hire a team of mathematicians was at Monero's birth (hindsight, amirite?), but the next best time is now.

Edit: The proposal section was heavily updated to incorporate concerns and suggestions from the community.

Edit edit: The amount was adjusted to 467 XMR to reflect a smoothing of the recent price fluctuations, after discussions in #monero-ffs.

Replies: 39
SarangNoether edited 2 months ago Weight: 327 | Link [ - ]

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!

SarangNoether edited 3 months ago Weight: 268 | Link [ - ]

Hello, sports fans! Sarang Noether here, with the second of three monthly reports for my current funding period. As usual, there's been plenty going on with Monero research projects, and I'm happy to give this summary of my work for the month of October.

First of all, the subaddress whitepaper discussed in my previous report has been completed, reviewed, and publicly posted here. Subaddresses give users the flexibility of posting separate unlinkable addresses at which they can receive payments, while simplifying the process of scanning incoming transactions. I documented the scheme (pioneered by kenshi84 and others in a pull request and subsequent intensive discussion), analyzed its security, and provided exposition about the practical integration of the scheme. Code is in the pipeline, and soon users will be able to take advantage of this great new feature.

The ongoing multisignature process is just that; still ongoing! Establishing a safe multisignature scheme, which allows a user to require more than one signature on transactions in a way that is provably secure (and not just dependent on protocol requirements) is a new and tricky business. There is existing code for the scheme, and my goal (along with my Lab brother Surae Noether) is to complete the security analysis, which provides interesting new and useful definitions for the cryptographic community. A code comparison is also underway to ensure that our academic understanding of safe multisignature math matches precisely with what our users see in software. A long process, but an important one.

Even more so than last month, I have devoted time to paper review and analysis of innovative techniques from the mathematics, computer science, and crypographic spaces. A new hash-based accumulator scheme promises an efficient way to prove membership or non-membership in a set without the requirement of a trusted manager. Up-and-coming work in aggregate signatures allows for compression of multiple signatures into a single one in an untrusted and publicly-verifiable way (but at the cost of some additional mathematical requirements on group structure). A new technique called proof of proof-of-work aims to reduce the verification complexity of a generic blockchain from linear to logarithmic. And in a non-paper topic, I have been working with some of the other developers to look into the use of randomness within Monero clients to ensure consistent and safe key generation.

One topic in particular deserves an extra paragraph. Surae and I have been deep in the weeds on a consensus protocol called SPECTRE that changes the way we might think about block structure. Instead of the standard blockchain, where Nakamoto consensus requires that we follow the longest single chain of blocks, SPECTRE replaces the structure with a directed acyclic graph. Correspondingly, a new voting protocol is established that makes the blocks in the structure (as opposed to miners) the voting parties in a way that offers robust security against a number of different types of attacks and allows for much faster confirmations. Perhaps its most intriguing property is that unlike Nakamoto consensus (which does not have scalable security based on block rate), SPECTRE can guarantee 50% attack security over a wide parameter space. The Lab has basic working code for the topology and voting protocol of SPECTRE, and we plan to continue our investigation of it, especially looking into how block headers scale with different possible graph structures, and the effects of different network conditions.

The next month of work, which is the last for this funding period, will see a continuation of work that addresses topics presented in the Lab's research roadmaps, my original funding request, and whatever new information comes our way. As always, academic research is dynamic; with a field under such rapid growth as cryptocurrency and information security, there is always more to investigate. My goal remains ensuring that Monero is always at the top of its game, regardless of what is thrown at it.

As always, I am open to questions and comments regarding this report and my work in general. It's been a pleasure working with the Monero community this month!

SarangNoether posted 4 months ago Weight: 213 | Link [ - ]

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.

anonimal posted 5 months ago Replies: 1 | Weight: 152 | Link [ - ]

After speaking with Sarang, I believe he will be doing Kovri work as well? Can this be amended to the proposal?

Reply to: anonimal
SarangNoether posted 5 months ago Weight: 153 | Link [ - ]

I'd like to spend a few more days working with RuffCT to get a better sense of the work required to get it verified. But yes, I want to get involved with Kovri.

SarangNoether posted 5 months ago Weight: 148 | Link [ - ]

You magnificent bastards...

ArticMine posted 5 months ago Weight: 148 | Link [ - ]

Donated 200.00 XMR

Kurious posted 5 months ago Weight: 147 | Link [ - ]

Just chipped in a few ;-)

pa posted 5 months ago Weight: 147 | Link [ - ]


monerodinero posted 5 months ago Weight: 146 | Link [ - ]

Donated! Welcome aboard Sarang!

SarangNoether posted 5 months ago Weight: 145 | Link [ - ]

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.

antw081 posted 5 months ago Weight: 145 | Link [ - ]


antw081 edited 5 months ago Weight: 145 | Link [ - ]

10 XMR donated on behalf of muff1nman.

SarangNoether edited 5 months ago Weight: 134 | Link [ - ]

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

xmrenthusiast posted 6 months ago Weight: 94 | Link [ + ]

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 [](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.

nioc posted 6 months ago Weight: 81 | Link [ + ]

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.