---
# System prepended metadata

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

---

---
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<sup>#zeros</sup> / 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.
