**Home Edition**

# Discussion notes #3: Semaphore: Zero-Knowledge Signaling on Ethereum
Presenters: Kobi Gurkan and Koh Wei Jie

Authors:
* Kobi Gurkan (Ethereum Foundation and cLabs) <>
* Koh Wei Jie (Ethereum Foundation) <>
* Barry Whitehat (Independent) <>

To be presented on 2020-04-27.

Resources:
* [Latest PDF version](https://docs.zkproof.org/pages/standards/accepted-workshop3/proposal-semaphore.pdf)
* [Miro Whiteboard](https://zkproof.org/workshop3-board)
* [Working Group](https://community.zkproof.org/g/WG_SEMAPHORE)
* [Additional related links](https://hackmd.io/@HtwXZr-PTFCniCs7fWFSmQ/B1AwbdI_8)
* [Ancient History](https://eprint.iacr.org/2006/454.pdf)

----

## Real-time notes
_Note taker:_ Markulf Kohlweiss

> Others are welcome to augment/annotate using notes. Add your name. ---Eran Tromer

Problem statement:

Privacy on public block-chains is hard. Semaphor is a semi generic gadged for signalling and set membership. Enables some interesting use cases.

Register their identity on an on-chain Merkle tree. Anonymously prove that their identity is in the set of registered identities. They can signal an arbitrary string once per epoch/external-nullifier. This is assured using a nullifier. This prevents double-signalling.

Attacker sees set of identity commitments and set of broadcasted signals. The attacker cannot link signals to commitments.

It has a shared trusted setup. Currently running an MPC to discarde toxic waste, build on AZTEC Ignition Ceremony. Only takes 5 to 10 minutes. [Q: Which round of the CRS generation is this?](/TFi5bD3HQ8G7sR2hQdsiQA)

Semaphore is Applied ZKP project flagship project. One-step away from production.

----
Charter Ideas

Goals:

- Include semaphore in the list of gadgets?
- Use semaphore for spam prevention?
- Gain confidence in security of hash-functions used by the construction (Pedersen, MiMC - own parameters)
- Improve interoperability, e.g. through high-level API for semaphore gadget, external nullifier specification
- Authors expectation from standardization
- part of a practice to bring someting to production
- use standardized primitives

Milestones:

- full description of an application --> Mixer
- external nullifier is the address
- describe the abstract protocol
- describe how abstract protocol can be parameterized with different algorithms/primitives and used in different applications
- discussion on detection of attacks
- formal security argumentdfdfsdf, different application should be based on same security argument, there may be different application level security guarantees.
- discuss which properties algorithms need to satisfy to securely instantate the abstract protocol
- validate that abstract protocol and its parameterization suffices for the scenarios ZK proof participants have in mind
- abstract the implementation to enable it as a reference implementation? With guidance

----

## Discussion topics

_Suggestions welcome! Please append at the end, and the moderators will incorporate into the schedule._

~15 minutes each, by default.

**1. Should Semaphor be added as a high level gadget? A framework? Is this widely useful? Let’s discuss applications!**

- decide separately what primitives to standardize and use those in high level applications
- clarify requirements of the functions / primitives (i.e.: merkle tree only needs something collision resistance)
- Security implications of breaking each of the primitives-> people can make own trade-offs
- UC framework? Define primitives in this way and in secure way through ideal functionality
- start with identifying ideal functionality
- issues? collision resistance hard to simulate?

**2. Choice of hash functions and security implications - what guidance should the community have?**

- Semaphore currently uses MiMC on chain.
- Other hash function could be supported improving interoperability
- This was pointed out as important for interoperability
- We should also give guidance on curves for public keys

**3. How to gain confidence in algebraic hash functions? Are bounties enough?**

**4. How do we advance interoperability?**

> Barriers to using zkInterface? ---EranTromer

> Commit and proof could be valuable ---MarkulfKohlweiss

**5. Applications**

- Semaphore RLN
- Anonymous Login, Kobi might be able to say more about this application
- does user have to wait for new external nullifier to loging after logging out
- Voting, can vote once for every external nullifier
- Mixers, a smart contract that sits on top of the semaphor circuit. The external nullifier is the address of the mixer contract. The signal is defined as the hash of the address designated to withdraw funds that is the receivers address. This is described in the paper. The sender provides an identity commitment and funds.

**6. How should we abstract the standard in order to allow for changes in the primitives?

**7. How do we test the adoption of the protocol / standard?**

**8. Why should ZKProof standardize something specific to Ethereum, why not have a more general proposal that is interoperable?**

**9. Have you thought about defining an ideal functionality and formally proving guarantees. We need to make sure there are no issues such as shielding/non-shielding bug from zcash**

**10. What should be the first milestones of the working group?**

**11. Should we consider recommending a method of detecting if the system is being attacked. This can in general be problematic in perfectly hiding schemes.

- some attacks are not detectable (toxic waste in CRS: in mixer case someone can generate proofs that are indistinguishable)
- unhiding data? Is perfect hiding more important than being able to detect attacks?
- not only commitm ent schems but also the ZK scheme is hiding
- have both hiding and binding commitments?
- about central party? mixers do not have it; depends on who issues the external nullifiers? It may be a governance qestions

**12.For the anonymous login use-case, say the user logs in and recieves a session-token. If the user "logs out", (i.e. their session token is invalidated), then they can't login again until the external nullifier is changed - is that correct? How often does the external nullifer get updated then in that case? **

Could deactivate external nullifier so admin could do it. Depends on design of the system. If based on smart contract or external / off-chain data base.