Chrysalis RFC Call - 2020-12-14

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