Nice, would love to see this funded!
Hire mathematician (and computational physicist) to join res[...]
SarangNoether posted this 7 years ago
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.
I would be more than happy to donate a fixed amount every month to keep competent people with good intentions working on the Monero project. It's very important to add the financial variable here because I, at least, don't expect people working for free in a project when everyone have bills to pay.
Thank you for this. I personally would prefer to move to a more stably-funded MRL, and I may have some ideas after my first three-month period comes to an end.
I like this proposal and thus approve it. However, I have a small remark with respect to the rate. More specifically, why is the rate almost twice as high as Surae's rate? In addition, it's also significantly higher than what top coders / contributors like MoneroMooo and anonimal asked for. In my opinion, the rate is, relatively speaking, a bit too high.
It's well known that moneromooo took a (surprisingly) extremely low rate for a person of his ability. I believe he said part of the reason for that is that he already had received a good chunk of XMR in the past from the community, which I'm sure has provided a cushion of sorts. But he's a very special case. I honestly think it was somewhat unfortunate he asked for such a low rate, not primarily because he could easily justify getting paid 3-5x more, but because his rate therefore cannot be used as a benchmark for anyone else. Where he asked for something like $30-40/hr (I don't recall the exact numbers), a senior developer of his ability (even completely ignoring the extreme speciality of his domain), in a contractual/consulting rather than employment setting, would normally be paid at a very minimum about $100/hr. And that's low for someone like moneromooo. I've seen brash and inexperienced intermediate devs ask for more simply because they think they know how to code in a production setting because they've got a CS degree. I've had some senior devs who were excellent self-managers, who had experienced many things in legit production settings, charge upwards of $200-250/hr. Excellent specialists sometimes go higher, upwards of $400-500/hr, believe it or not. And it's actually often justified, because of the high value produced by their output for their customer. Their work is used to produce a return of multiple times the cost – otherwise it can't really be justified. In fact, one silly metric used to approximate this is that for the acquisition of a team by another company (not talking about any IP, brand equity, products, traction etc), one should multiply the number of engineers on the team by $1M. (This of course is based on the assumption that you only hire solid people.)
I think it's important to look briefly at why rates like $100/hr can be justified in terms of expenses for a contractor. A solid 7-billable-hour day would be $700. (And few can put in a solid day of billable hours without screwing around a bit, or spending their time researching or reworking something they ought to have planned better and therefore shouldn't be charging near their full rate for.) Now let's say this rate is for a month-long project during which the contractor will be working 5 days a week. That nets out at $14k for a solid month of (140) hardcore billable programming hours during which zero messing-about was done. But already, a good 45% of that is going to go to special taxes and operation costs which consultants must pay. Then add on top that they must pay for their own medical/dental insurance. Then add onto that the fact that consultants must do their own bizdev (which in this case takes the form of building community trust, doing the FFS proposal, managing feedback, responding to requests, etc) and generally hop from project to project – which means doing completely unpaid work without any job security for who knows how long. Pretty soon you're not terribly far off from normal employee rates of around $5-6k/mo post-tax. And in terms of where all that goes, a good $2-3k/mo could immediately go to housing alone. Another $700-1k/mo could easily go to food. Then another $500 for medical insurance (since no employer). Another $500 for potential car payments and insurance. Don't forget utilities like internet and cell. Then add on top of that the fact that if he's left with no money at the end, he can't save anything for a rainy day, and working on Monero long-term is suddenly not viable anymore. (So there's also the tangential argument to be made that FFS proposals need to be a viable alternative to good employment or non-money-grabbing consulting.)
Even if we ignore the special costs to consultants (vs employees) and treat it as a simple salary, $150k/year is really not that high for a person of Sarang's (reported) very special expertise. I would venture to guess that if he really went about it the right way, he could end up making a $200-300k/yr base salary as an employee, if not more, depending on experience and ability. Of course, I don't know him personally, and I've never worked with him, so I can't say whether he actually could justify this, but my point is, it's not that crazy at all. It really depends on (a) how seriously he takes the job, (b) how ready he is to live with having to be accountable for every billable hour, and (c) how good he actually is (i.e. his output/hr and the quality of it). If he's ready to have to be accountable for his work output during every billable hour - not that this is an hourly gig! - then it's actually a good thing he charges that much, because that means we know it means he's going to pump out a lot of value over a short period of time and not make excuses. And I get the feeling he is already treating the gig like this given the places he's worked. But if he's not really operating at that level, where he plans to put every business hour into this as a fulltime job, then 700 XMR for three months is too high. So what I think could help here is if Sarang could talk a little bit about how he sees this gig, whether he's going to be putting his all into it, and whether he knows what I'm talking about in terms of value/hr – basically, diligence. Not knowing him personally and not having seen him work, I couldn't tell you that. I just wanted to provide a bit of a reality check that if he indeed operates at that level, the figure is not so crazy. In fact it would be in the community's best interest to make sure he's above the threshold of pay where he no longer has to worry about money, because it means he can worry about Monero instead. And I would say that if Sarang's rate is only able to found to be too high in relation to the rate requested by others, and not in relation to the value he's generating, then it only means we need to start paying Surae, anonimal, etc more so that they don't have to worry about money either.
Hope this is contributive.
I'd be fine with the rate, but what I'm less enthusiastic about is the defined deliverables. This is a lot of money and I definitely think Sarang is deserving of such a rate, but apart from helping Surae, there's little in the form of a tangible set of deliverables. I also think that being hired the equivilent of a full time wage clashes with the fact that Sarang does have a university position. How can we justify paying an hourly rate equivalent to a full time position, while he also gets a paid role at Duke University?
I think this proposal needs some better defined deliverables (something that can actuially be measured) and a proper definition of what role Sarang proposes to act as, as well as making sure that he can fit this role in with his other University work (because lets be honest here, his Uni life, WILL take priority over obligations to the FFS contract. I think users need to be assured that he can incorporate his obligations to the FFS as well as his daily obligations as a University employee.
Now, as a (yet to be anointed PhD) researcher myself, I know its tough to define research deliverables (real tough) because research almost always doesn't play nice with deadlines, but even still, I think this proposal needs more detail and focus. For example, lets at least set out hours per week spent working as an MRL consultant at a bare minimum in this proposal.
Your concerns are justified, and the situation could be clarified a bit. For one thing, if the community wants, we can perhaps move MRL to a model where individual researchers are not funded through FFS, but a certain group of participants in MRL are decided upon as the lab coordinators, and the lab is collectively funded. This could eliminate questions about how individual researchers decide on funding amounts, etc, and will allow folks who want to participate in MRL who have academic experience can actually engage in productive negotiation about salaries and funding. This is the direction I plan on taking MRL eventually, especially if we get any grants. But this is a rather higher-level thing that will require a lot of discussion. In particular about Sarang... If your concern is that Sarang's proposal is not well-defined, I refer you to my previous posts in my own funding thread about the MRL research roadmap. MRL is trying to get those things done. Sarang is offering his assistance in that road map and in granting his considerable expertise while modifying the road map as the journey unfolds. I invited him to apply specifically to assist me with that roadmap.
In terms of deliverables... Well-defined deliverables are nearly impossible in research. Maybe you think our deliverables should be published papers. This incentivizes least-publishable-units, which are crappy little tiny math papers that have literally the least amount of information possible in order to get past reviewers. Maybe, as you say, you think deliverables should be measured in hours of work. This simply leads to a "billable hours" situation, which no one really wants either. Maybe you think the deliverables should be some new cryptoscheme. It's entirely possible that, as mathematicians, Sarang and I put in 40 hours a week each for 2 months working on a scheme/set-up. Then, last minute, one of us notices a small math mistake, because we have PhDs, and we scrap the entire project because it's irreconcilably insecure. The desire for well-defined deliverables in this case incentivizes us to push out insecure or under-vetted schemes. If the community gets pissed off and deprives us of compensation for lots of PhD-level work because it didn't result in a deliverable, this would be wage theft if the FFS were a company liable to being sued by its employees.
Maybe you think "Okay, well, if we can't have very well-defined deliverables and we are paying for abstract research with no guaranteed payoff, maybe we only need one mathematician." At which point, I can say confidently: okay, well some of our plans are going to take years and years to get off the ground. To give you an idea, five (count 'em: FIVE) mathematicians at a Chinese university just put out a new paper on zcash with a new scheme for fast transaction processing (here)[https://eprint.iacr.org/2017/684]. Monero is not going to keep up with only one mathematician.
We have several people with lots of crypto and CS experience already contributing to the team. They are INVALUABLE. But we are in an arms race (literally: the bad guys want to break our crypto, and we want to make it stronger). If we want to put any sort of reasonable dent into any sort of research roadmap, we have to accept the notion that we need several people. Moreover, in my opinion, we need to accept the idea that research and "deliverables" are often competing ideas that aren't directly resolvable.
As a final note for clarification... Sarang teaches in the summer for a teaching program hosted by Duke. He is a seasonal employee there in the summer for a few weeks at a time, not full-time or salary. He is in China right now for that program. I also plan on teaching for this program (Duke TIP) next summer; I'm going to see if I can specifically teach a course on cryptography and cryptocurrency, for example. I certainly won't be seeking funding from MRL for that time, but Sarang won't be seeking funding while he is teaching either, AFAIK.
Thanks for the input. And I agree the deliverable part is not going to be easily defined, I mentioned it in case it could be defined. If it can't be because the nature of the work makes it impossible, thats fine, it wasn't so much a criticism, but more a "it would be nice if". So I appreciate that this can't be done, but I'll make mention that the proposal itself does not tell me exactly what he was trying to get funding for. You mention that he will be assisting you? Then a link to your funding page where everyone can see what you are working on would be appropriate. I think that'd help get it funded faster too. I'd hate to see the proposal flounder for weeks because people are hesitant to contribute due to lack of information.
Also, as I said in my original comment, aside from the work, its important to know that he actually has time to do this work if he has other unrelated employment obligations. I don't want to raise expectations for him being paid to fulfill the equivalent of 40 hours work a week on Monero when he in fact has a full time position at Duke as well. That's not clear in the proposal (thankyou for clarifying his circumstances though) and I think it is important that users that fund this commitment have clarification that he is not being overly burdened. I very much want Sarang to be a part of this community funding effort, make no mistake, but I think communication of what is going to be involved in this funding is important and I think little things like this will make a big difference. That way no one is left in the dark and you guys can get funded in a flash and focus on more interesting topics. :)
You magnificent bastards...
I believe Sarang will add considerable value to the project. His skills are impressive, and we need him in our MRL to keep our project set apart and bleeding edge crypto. I personally will contribute, but I'm getting beat up in this bear market. Many of the monero I've purchased at a significantly higher price than where we are now.
This is awesome, though I have a question. Would you be willing to start early, if this is funded early? That is, the August - October period would be the period you're paid for; but it would probably make a lot of us more comfortable about this pay rate if you would make yourself available in advance of your FFS work to assimilate and catch up. This proposal is quite a bit more than what Surae asks for, so perhaps it would be like a gesture of good faith that you make a community presence and assist Surae in his MRL endeavors. And then when August 1 comes, you'll already have picked up a head of steam.
"complete trust in both the underlying mathematics and its implementation" This is what MRL needs to produce and publish everywhere. The potential for an order of magnitude in market cap move is here. Sarang already values aspects of our project. Its time to leverage him.
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!
After speaking with Sarang, I believe he will be doing Kovri work as well? Can this be amended to the proposal?
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.