---
tags: meeting-minutes
---

# Chrysalis RFC Call - 2020-11-09

## Participants

- Wolfgang
- Andrea
- Luca
- Gal
- Thibault

## Topics

### RFC Status

#### Merged

https://iotaledger.github.io/protocol-rfcs/

- [RFC-0005](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0005-white-flag/0005-white-flag.md) (White Flag):
- Remove old Bundle/Tx structure:
- done: https://github.com/iotaledger/protocol-rfcs/pull/30
- [RFC-0008](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0008-weighted-uniform-random-tip-selection/0008-weighted-uniform-random-tip-selection.md) (Weighted URTS):
- Everyone is happy with the changes to reflect the current implementation (in Hornet)
- @all approve
- [RFC-0012](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0012-milestone-merkle-validation/0012-milestone-merkle-validation.md) (Milestone Validation):
- Remove old Bundle/Tx structure:
- State mutations -> UTXO mutations (circular transactions are not possible with UTXO)
- Tx Hash -> Message ID
- Blake2b-512 -> Blake2b-256
- @Wolfgang create PR

### Open Questions

#### `Network ID` field in the message

- Purpose:
- Distinguish between different (private) networks
- Detect/handle breaking protocol changes independently of the network/peering layer
- Prevent replays of the same message in different networks without PoW
- Have network/version as part of the Message ID (for MSs, queries, ...)
- Since the MS payload signs the Message IDs, replays of the MS payload to a different network is not possible.
- Decision:
- It should be included as a single message field.
- It should encode the network (mainnet, testnet, private x, ...) as well as the protocol version.
- It should be a `uint64`. This offers a good compromise between size and accidentally having the same value for incompatible situations.
- Local snapshots (and probably peering) should use the same value.
- It should not be signed to potentially allow replays of the same payload (but with different Message ID and new PoW).
- Nodes should reject message with an incompatible `Network ID`. (What actually causes a protocol version bump is a case-by-case definition, but as a rule of thumb consensus changes are breaking.)
- (Perma)nodes trying to sync across different protocol versions is a special case and does not need to be considered for regular nodes (same premise as when introducing white-flag).
- How the `Network ID` is constructed is an implementation decision. It does not need to be part of the Message RFC, but it is still very relevant for the node implementations. Options:
- Hash(`Network Name`+`Protocol Version`) (probably the most promising)
- Use a couple of static bytes for the "Network"
- Combination of the above
- @Gal update the PR to include those changes
- After that, [RFC-0025 (Local Snapshots)](https://github.com/iotaledger/protocol-rfcs/pull/25) needs to be adapted