---
tags: meeting-minutes
---

# Chrysalis RFC Call - 2020-12-08

## Participants

- Wolfgang
- Luca
- Gal
- Thibault

## Topics

### Chrysalis Stage 2

- [Multisig](https://hackmd.io/@iota-protocol/r1lIMILiv)
- There are almost equivalent 2nd layer approaches, so we don't see the need to force protocol changes at this stage
- Andrea is talking to Exchanges and BisDev. We will revisit this, once he has more input
- [Dust](https://hackmd.io/@iota-protocol/r1t4qlBiP)
- Slightly new approach by Gal:
- Introduce a new output type serving as an opt-in to accept dust on target address
- Allow 100 dust outputs (< 1 Mi) per each Mi in those marked transactions
- This protects against involuntary spam on (rich) addresses and potential race-condition attacks because of those
- It could make sense to limit those markers to the owner of the private key:
- Prevents any 3rd party dust
- Makes definition/validation of _SigLockedDustDepositOutput_ much more complicated
- It is probably not worth the effort.
- TODOs @gal:
- Find a better name for the new output type to better distinguish between dust outputs and this new type.
- _SigLockedDustDepositOutput_ below 1 Mi must be forbidden
- Clarify validation rules and add examples
- Go for KISS, i.e. 100 outputs per Mi, no non-linear number or weights. We will present this to other projects use-cases/projects to make sure it is sufficient.