---
# System prepended metadata

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

---

---
tags: meeting-minutes
---

# Chrysalis RFC Call - 2020-12-14

## Participants

- Andrea
- Gal
- Thibault
- Wolfgang

## Topics

### Chrysalis Stage 2

- [Multisig](https://hackmd.io/@iota-protocol/r1lIMILiv)
  - Andrea is reaching out to figure out the precise requirements from exchanges and other partners
- [Dust](https://github.com/iotaledger/protocol-rfcs/pull/32)
  - Validation
    - Change: Within the same output type only one output per address. However, there could be one `SigLockedDustAllowanceOutput` on A and one `SigLockedSingleOutput` on A in the same transaction.
    - Make sure that the validation rules are well-defined and -explained for a transaction decreasing the deposit amount, i.e. a transaction consuming a `SigLockedDustAllowanceOutput` on A and creating a `SigLockedDustAllowanceOutput` on A.
  - Add more details:
    - Explain that "foreign" `SigLockedDustAllowanceOutput` are allowed and do not cause issues, see https://github.com/iotaledger/protocol-rfcs/pull/32#discussion_r540862717.
    - race-conditions:
      - Issue itself
      - Potential mitigation, e.g. send dust transactions to oneself until quota is full
      - Highlight worst-case: An attacker can _always_ issue a dust transaction _before any_ honest transaction. This is the cheapest way to block a spend of a `SigLockedDustAllowanceOutput`
      - See thread: https://github.com/iotaledger/protocol-rfcs/pull/32#discussion_r540175897
 - [Bech32 Address Format](https://github.com/iotaledger/protocol-rfcs/pull/20)
   - Has been updated from `iot` to `iota`
   - Proposed changes in address version are not public (in a PR) to avoid confusion and different implementations in different parts of the system
   - Change in the HRP is a very small fix (change of constant): should it happen now or batch with other (breaking) changes.
