---
tags: meeting-minutes
---

# Chrysalis RFC Call - 2020-08-18

## Topics

### RFC Status

- [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):
- **Depricated**
- Modified in Hornet implementation; "healthy spam": works™
- Should be re-visited later
- [mdBook](https://github.com/iotaledger/protocol-rfcs/pull/16):
- Merge it now
- Finding a nicer style can be outsourced to frontend later
- @all please approve https://github.com/iotaledger/protocol-rfcs/pull/16

### Chrysalis Stage 2

#### Missing RFCs

##### Binary W-OTS

@Vlad @Wolfgang

- Computation of the "bundle hash"
- Normalization
- Security of Kerl hash chain
- GitHub discussion: https://github.com/iotaledger/protocol-rfcs/pull/18#discussion_r471824298

##### Payload Registration Process:

- Similar to [SLIP-44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) or [SLIP-173](https://github.com/satoshilabs/slips/blob/master/slip-0173.md)
- Just a table with Payload ID, Name and link
- Creation of the RFC will be postponed until Message RFC and payload types are clearer

@Gal double check in Message RFC: Unknown/unsupported payloads must still be gossiped, but the actual content can be ignored if the node does not care.

##### PoW

- Plain Curl is not feasible:
- `nonce` should be at a fixed position
- Curl is only defined for multiples of 243 trits
- Curl is too slow especially for larger messages
- Batched Curl is very difficult due to arbitrary message lengths
- Solution:
- Compute the Blake2b-256 hash of the message *excluding* the last 8-byte for `nonce`
- Convert to 192-trit string using the `b1t6` encoding.
- Append 0,0,0 to reach trits
- Take the 8-byte little endian encoded `nonce`, convert it into 48 trits using `b1t6`, append
- Compute the Curl-P-81 hash of those 243-trits (always exactly one block)
- Count the trailing zeros
- PoW = 3^#zeros / len(message)
- Naive verify implementation (not batched, etc): < 0.1ms
- Existing SW/HW miners can be converted easily
- PoC implementation: [github.com/wollac/iota-crypto-demo](https://github.com/Wollac/iota-crypto-demo/tree/master/pkg/pow)
- Open Questions:
- Score threshold? Start with something that is close to the current MWM.
- Should the 3-trit padding be in the middle or in the end?
- The larger the message the more can be added for free.

@Wolfgang create a new RFC

#### Snapshot Format

- Snapshots need to work for Hornet and Bee
- We need an RFC to coordinate
- Blocked by the "Signed Transaction Payload" RFC
- Add a section describing the migration from account model to UTXO:
- Create a dummy Tx with exactly one output consisting of the total funds on each address.
- Tx hashes need to be consistent.

Written by Bee/Hornet team; @Luca DRI

### Open Questions

- Capitalization of `Feature Name`?
- We will us all lower case with dash.
- @all please check in each PR that this is correct
- [bech32-address-format](https://github.com/iotaledger/protocol-rfcs/pull/20)
- HRP `iot` / `tio` ok?
- @Wolfgang escalate this question
- [Milestone Payload](https://github.com/iotaledger/protocol-rfcs/pull/19)
- [Break in layer concept](https://github.com/iotaledger/protocol-rfcs/pull/19#discussion_r466194210)
- We will keep the current solution.
- DevOps requirements for COO private key
- @Angelo schedule a call with Andrea
- Ed25519 vs Ed448
- Ed25519 has much better hardware/software support. The required additional security of Ed448 is not really necessary.
- Quantum Robustness
- Non quantum signature scheme is fine.
- Security review
- We should get a security review of the finalized RFCs.
- Network ID
- A uint64 is sufficient
- It makes no sense to only have that in the MS payload. If desired it should be in the Message.
- Milestone index
- should be a `uint64` instead of a `varint`
- @Angelo make discussed changes in the RFC and removed solved unanswered questions
- [Tangle Messages](https://github.com/iotaledger/protocol-rfcs/pull/17)
- PoW: See above; can (should) be migrated later
- Examples: Serialized message with valid PoW
- "Indexation" payload is important as it is relevant for certain use-cases.
- We need to describe all payloads in more detail with example
- @Gal will add (temporary) links section for all the missing payloads
- @Gal consider adding a column with message / Tx payload or similar
- `varint` and limits on lengths and counts
- It is very difficult to find tight limits without knowledge of network usage, use-cases, dust prevention...
- This is just a design decision or matter of personal preference. For all practical purposes both solutions will work.
- Pros `varint`
- Very flexible, no need at all to think about limits or choose larger bounds just to have bits reserved.
- By far the most compact representation, as most of the times values will be small even for larger bounds.
- Grammar is as simple as it gets.
- Consistent with protobuf wire types.
- We have dynamic arrays. Thus, the length will not be fixed anyways.
- Cons `varint`
- Elements don't have a fixed size. This prevents accessing array element without parsing. However, probably everything needs to be parsed anyway for validation.
- Same value has different encodings depending on the number of leading zeros. This needs to be considered during validation/serialization.
- When parsing varints into a struct, it needs to always reserve the largest possible type (probably uint32) anyway.
- Parsing is slightly more compatible to implement than for fixed integer types.
- Mixing `varint` with fixed size integer seems inconsistent.
- @Wolfgang prepare two exemplified alternatives all `varint` vs. all fixed int. And put this to a vote.
- [signed_transaction_payload](https://github.com/iotaledger/protocol-rfcs/pull/18)
- Add examples once the types are finalized.