Sanaz Taheri

17/Waku-RLN-Relay: Standardizing the interface of rln/rln-relay membership contract

2

As of now, there is no standard contract API for the rln membership contract. There are currently two interfaces defined that live in two different GH repos that have discrepancies....

Incorporating fee option in the rln contract

2

A replica of https://github.com/status-im/nim-waku/issues/840, just moved it here in rfc repo as it relates to the vac specs. # Background We held a sustainability workshop last year and we came...

# Problem In the waku-rln-relay spec, circuit parameters are not clearly specified. This will affect the power-of-tau and circuit-dependent ceremonies hence the generated prover/verifier keys. # Acceptance Criteria - [...

17/WAKU2-RLNRELAY: Spamming through multiple registrations

6

## Problem In RLN using Semaphore and SSS, the number of signals per registered user per epoch is limited and guaranteed to be one (otherwise the user gets slashed) however,...

14-WAKU2-MESSAGE: Security issue related to unencrypted timestamp of WakuMessage

7

# Problem While currently, the `timestamp` is not part of the relay [`Message`](https://rfc.vac.dev/spec/11/#message-fields), it is always accessible in plaintext even when the `WakuMessage` is encrypted. This is because encryption only...

14/WAKU2-MESSAGE: Lack of integrity for `contentTopic` and `timestamp` in waku messages

1

# Problem The problem is that currently there is no method to ensure the integrity of the `contentTopic` and `timestamp` fields of waku messages. As such, an adversarial node can...

14-WAKU2-MESSAGE: Validating WakuMessage sender timestamp

2

# Problem Waku messages carry a timestamp that is generated by the user. As mentioned by @jakubgs in https://github.com/status-im/nim-waku/pull/681/files#r676126058 > In general, any functionality that relies on timestamps set by...

11/WAKU2-RELAY: libp2p FloodSub & GossipSub: Security Analysis

2

## Problem To analyze the security of the libp2p FloodSub & GossipSub protocols based on https://github.com/vacp2p/specs/issues/244. In this analysis, and for each security feature resulted from https://github.com/vacp2p/specs/issues/244 the following items...

GENERAL: Use snake_case field names for protobuf messages

6

## Problem As suggested by @D4nte: ~~https://github.com/vacp2p/rfc/pull/344/files#r613679908~~ https://github.com/vacp2p/rfc/pull/344#discussion_r613679908 we may want to follow the protocol buffer style guide and use snake_case for field names: https://developers.google.com/protocol-buffers/docs/style This issue is to get...