---
# System prepended metadata

title: Chrysalis RFC Call - 2020-12-08
tags: [meeting-minutes]

---

---
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. 
