**#4 Home Edition**

# Proposal: Framework for Snarky Ceremonies

**Moderator:** abhi shelat
**Presenters:**

**Authors:**
* Markulf Kohlweiss
* Mary Maller
* Mikhail Volkhov
* Janno Siim

To be presented on 2021-04-27.

Resources:
* [Latest PDF version](https://docs.zkproof.org/pages/standards/accepted-workshop4/proposal-ceremonies.pdf)
* [Miro whiteboard frame](https://miro.com/app/board/o9J_lJQRFxQ=/?moveToWidget=3074457357481295789&cot=14)
* [Additional related links](https://hackmd.io/@workshop4/links)
* [Related conversation]()

----

## Real-time notes
_Note Taker:_ Anca Nitulescu & JB (on paper to be uploaded) & Markulf Kohlweiss

Nicolas Gally, pointed out that filecoin used a drand randomenss beacon for phase 1 as well.

Discussion:
Several types of proofs for [BGM17] - not all are UC
Consider simplifying verification procedure of the ceremony -> lighter specification

- [BGM17] is in n-1 setting. Q: how do you deal with the abort problem?
- this is not a problem because generation is sequential
- coordinator who invites participants to contribute trapdoor -> update previous crs
- abort is equivalent to the coordinator removing one participant
- you can't combine forks, coordinator takes care of avoiding forks

- cheaters are ejected, Q: can you do it less than $n$ rounds?
- authors do not have intuition for this, seems a different type of protocol
- you can cut the protocol at any point and there is an output
- powers of tau: 17 contributors in first phase, then second part

- Q (Markulf): Do practitioners need a beter specification for the ceremonies. What was the most challenging
- are there attacks to try to isolate participants? Not aware of those, do not affect correctness
- it is a centralised hub -> on github
- targeting one participant BGP highjacking attacks -> Aztec had a high network overhead, participants got timedout, not an attack
- A: had to consider timing as well, DoS attack is not feasible in practice
- DoS: reduces trust in the network, it does not break soundness
- each computation takes hours (exception Tornado), participants can ask for extra time slots
- Mary: does not seem a rational attack

- Markulf's remark: Very theoretic description of ceremonies, but not adapted to human aspects of participants (like Telegram communication etc)

Misha: our ceremony descriptions capture one-phase ceremony
do people need a description of points one has to look at in a ceremony?
- Daniel: Value in adding those aspects around the description in the document. Is there. acorect level of abstraction that applies to these ceremonies?
- Misha: our definitions apply to 1/2-phase ceremonies, they are general

- Thomas Kerber: the outputs of the ceremonies are reusable, it may sense to standardise a reference string... What level of a practicioner we need to target?
- target first people who use [BGM17]
- there is a software that can be modified to be used for Goth16 instead
- what about writing a verification tool for [BGM17] ceremony?

- Thomas Kerber: In many cases, it makes more sense to use something transparent instead. If not enough participants the resulting SRS is not trustful
- if you have at least one participant you trust, then the ceremony should be trusted
- not trivial to make the statement

- AntoineR (in chat): If we want to standardise the output of a setup, we must also standardise message format between contributor and coordinator, which means, we need to settle for, say the use of point compression, the serialisation of points etc; so that tools can be written against this standardised MPC output

- Markulf Q: Are there other situations where would like to standardize such formats?
- Point serialization sort of depends in the curve you use etc. Depending on the number of remaining bits in your limb representation