Proposal FAQ

Now that we have spoken with most of the groups, we wanted to reiterate a few things about the proposal and our expectations thereof.

Proposal 

We expect roughly the following structure for your proposal:

• 1/3: sketch the context and problem, and maybe highlight a specific usecase that you’d like to address
• 1/3: explain how related work currently tackles the problem (mostly based on the papers you currently looked at). You’d probably want to highlight some relevant properties (fast/slow, O(n^4) communication, no/one/multiple servers, etc.)  of these solutions.
• 1/3: sketch a research / solution direction that you’d want to explore. Typically you’d want to relate this to (1) the usecase / problem; and (2) use some of the properties to point out how this direction is different from what already exists.

We do not have formatting requirements for the proposal but we do strongly recommend to start using LaTeX immediately. The proposal should be 1 to 2 pages long. Please prefer quality over quantity. We’d much rather read less, but well-written text. This also means you should proof-read what you submit.

Research Directions

• Your proposal should clearly specify a specific research direction that you want to try to explore as part of this seminar. However, you will not be judged at the end of the seminar whether you managed to achieve your goals in realizing this direction. Research often requires changes, and we expect that might happen here as well. Use your meetings with us to talk about potential changes in direction. We’re happy to help.
• We will also use your research direction to provide feedback on what you currently have in mind. This way we can warn you about feasibility, and hopefully, point you to more specific papers that are relevant to what you’d want to do. (Of course, you are also still expected to find papers yourself)

What should we work on?

• Most importantly: pick something that excites you! We’re happy to help fine-tune later to make sure it is feasible. If you don’t (think) you like cryptography, just don’t go there. If you don’t like implementing solutions, think about proposing something else.
• If you want to validate an idea/direction, don’t hesitate to write the 2-3 line summary on mattermost and we can quickly confirm whether that works or not.
• If you are really stuck: papers often make claims about things that don’t work. But the dirty secret is: often they do better than people think! Might be a good direction to explore.

 

Common Feedback

* Motivation: make sure that the project you propose fits with you motivation. Often problem setting is too generic to start off with, and then steps are missing to come to the concrete solution you propose.

* Related work often very disconnected from what *you want to do*. This makes it hard to read.

* Sort references alphabetically, not in order of occurrence

* Using things you didn’t introduce. E.g., In a system with a Verification and tally server, you should first mention that these two exist before you can reference “the verification server”

* If properties matter introduce them before, to signal that you care about these.

* Don’t talk about things that are highly specific “magic gold-plated screwdriver method” as if everyone knows what they are. If you didn’t know these up front, maybe your reader doesn’t either

* No need to repeat citations all the time, especially for named systems.

* Do not use “…”, use etc. or rephrase better.

* Do not use contractions in formal writing.

* When citing papers, only cite ePrint / arXiv version when no other option is available

* Be consistent and respectful with capitalization (e.g., Tor, not TOR), usually good to follow the original work.