---
tags: meeting-minutes
---

# Chrysalis Sum

## UTXO Transaction Layout

### Design Goals
1. Create a self contained transaction structure that describes the entire transfer
1. Efficient queries of the memory model
1. Extensibility
1. Define hash locks

### Proposal Discussion

#### Wolfgang's Proposal
https://hackmd.io/@CcRtfCBnRbW82-AdbFJUig/H1zu0q7p8

This is our reference proposal.

Open Questions:
1. Should we have a credential index? (We think yes)
*Answer:* We should have a credential index. Inputs should be sorted with the following rule: Each input's credential index should be smaller or equal to max seen plus 1. We start with 0.

2. Should we aggregate inputs from the same address under one sig?
*Answer:* yes, in case we find a use case that doesn't support it, we just don't compress

3. How do we handle additional fields or metadata? (when we talk about serialization we will get back to this)
*Answer:*We have generic payloads. Before the payload we have a byte reserved for the type. We should have a list of default types.
4. Find example payloads?
1. Indexing (tagging) payload
2. Colored coins
3. Message payload
4. Indexed message
5. Composite payload

### Gal's Proposal
https://hackmd.io/@cIrs3AfUSq2uSeQ2tBF9fw/rJoT5xIT8

Attempted to create a non-standard UTXO schema.
We decided to reject it, since the promised benefits can actaully be achieved with a more standard UTXO schema.

Open Questions:
1. Should the signature be part of the Tx hash?
Answer: Currently yes. The transaction becomes susceptible to signature malleability attacks (create conflicts without the private key), but currently we are not using malleable sig schemes. If not, nodes must not filter out duplicate Tx hashes as the signatures could be different.
TODO: reimplement WOTS so it won't be malleable

### Luca's Proposal
Similar to Wolfgang

Open questions:
1. How are addresses encoded in the output? Human readable encoding (for unity)? Or something more compact? (We shall answer this after we finalize address encoding)
1. Should we have a checksum (probably no)?
1. The used signature scheme can either be encoded as an output type (opcode) or as an address type, which one is better?
Encoding as output type allows for smaller addresses in the tx; encoding as address type reduces the number of opcodes as different types must not be combined with all signature schemes.

### Thibault's Proposal

Conclusions:
1. Signatures should be separate from inputs because it makes serialization easier. (one can just serialize the unsigned transaction part and then sign this; if the signatures are fields in the inputs one would need to set them to 0 just for signing)
2. PoW should be linear to the number of inputs. PoW on X inputs should always be less than PoW on X transactions in order to encourage "bundling" of transactions.

Open Questions:
1. Why don't other cryptos have credential indexes but assume 1-to-1 relation?

Answer: Makes some MPC calculations more complicated https://bitcoin.stackexchange.com/questions/73870/why-is-the-signature-hash-different-for-each-input-in-a-multi-input-transaction?rq=1

### Transaction Field

https://hackmd.io/@XFC6dFQkSiOpICDucms41Q/ByUydJzkw/edit

## Messages

- Message Definition: A vertex in the Tangle that approves 2 other messages and contains a payload.
- Transaction Definition: A payload of the message that performs a (non-zero) UTXO value transfer.

> **Note:**
Different messages can contain the same transactions (reattachments).

### Message Layout

1. Version
2. Parents
4. Payload Type
5. Length (serialization)
6. Payload
3. Nonce

*Types:*
Message ID - BLAKE-512 hash over the entire message (all fields)
Version - 1 byte
Parents - 64 bytes (512 bit) each
Payload Type - 1 byte (maybe varint)
Nonce - 4 bytes (uint64)

### Value Payload layout
1. UTXO (copy-paste)

Open questions:
1. Signed timestamps are required for hash lock contracts. (can be specified using new types, not part of the first iteration)
2. Where are the colored coins?

Answer: later on

### Other Payload Types

#### Milestones

1. Index
3. Merkle root for proof of inclusion
4. Signature of the entire message excluding the nonce
*Types:*

Index - uint32
Merkle root - 64 byte (BLAKE-512 hash)
Signature - byte array, depending on the used signature scheme

Open question:
1. Should we record the last message hash of the last milestone?
Answer: no by the Democratic process
2. Should we find a new sig scheme? (talk to Vlad)
3. Should we have larger PoW difficulty for milestones as a DoS Protection mechanism (depends on the answer to 2)?

#### Signed Data

1. Byte Array
2. Public Key
3. Signature

### Unsigned Data

1. Byte Array

### PoW
Same as before. Use Curl (unless CFB sues us).

#### PoW for Security
##### Attacks:
1. Spamming invalid milestones
2. Value transaction spam (Dos Vector)

#### Open questions
Proof of Work:
1. Do we need to have different PoW difficulty for different message types?
Answer: Currently we keep difficulty the same.
We may change when an active attack occurs.
2. TODO: Test how much PoW we save if we batch inputs
3. Should we have an unsigned tag in the message (shard marker)?
Answer: it can be some payload

## Serialization

Protobuf is not a possibility since deterministic serialization is not guaranteed. (See https://developers.google.com/protocol-buffers/docs/encoding#implications)
Assuring deterministic behavior is easily achievable, but doing so would require changes/additions not part of the protobuf spec/implementation, so it probably does not outweigh its benefits.

So we have two options:
1. Manual
- Advantages:
- Performance not library dependent
- Will only implement stuff we actually need
- The validation scheme is part of the implementation
- Cons:
- You have to write it yourself
- No nice domain language unless we create it
- Fix your own bugs, more error prone
- Not standardized
2. CBOR
- Advantages:
- Has IoT in the name :-))))
- It is very specified and went through RFC spec'ing
- Good tooling (Debugger)
- Has its own domain language
- Caradano uses it
- Disadvantages:
- We will only use a small subset of the features, some features should probably be explicitly disabled/forbidden.
- JSON like. Cannot support fixed size arrays.
- Domain language is not wide spread.
- The implementation are community based.
- Caradano uses it

## Address Encoding
We use [Bech32](https://en.bitcoin.it/wiki/BIP_0173) as the encoding for the human facing version of the address.

Prefix:
iota/tiot - 4 bytes

| Field Name | Type | Description |
| ---------- | ----------- | -------------------------------------------------- |
| Version | byte | Denotes the version and the used signature scheme. |
| Data | Array<byte> | The raw digest bytes. |

#### WOTS Address - (AddressType=0)

| Field Name | Type | Description |
| ---------- | --------------- | ----------------------------------------- |
| Version | byte | Byte value 0 / Denotes a Ed25519 address. |
| Digest | Array<byte>[49] | The T5B1 encoded trinary digest. |

TODO: show WOTS address example

#### Ed25519 Address - (AddressType=1)

| Field Name | Type | Description |
| ---------- | --------------- | ------------------------------------------------------------ |
| Version | byte | Byte value 1 / Denotes a WOTS address |
| Digest | Array<byte>[32] | The BLAKE2b-256 hash of the Ed25519 public key is the digest |

TODO: show Ed25519 address example

## Next Steps

1. Figure out some nice way to implement our layout.
2. Create Message RFC document (give an example with unsigned data payload). Add a table with links to the payload. Keep on updating it.
3. Create a signed transaction RFC
4. Create a milestone payload RFC
5. Create a signed data payload RFC
6. Create an indexation payload RFC
7. RFC for address encoding
8. RFC for colored coins
9. Multisig - BLS discussion