Skip to content

Commit

Permalink
Time and allotments description
Browse files Browse the repository at this point in the history
  • Loading branch information
@daria305
daria305 committed Jun 5, 2023
1 parent e109330 commit 9c9af7c
Showing 1 changed file with 32 additions and 22 deletions.
54 changes: 32 additions & 22 deletions tips/TIP-0045/tip-0045.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -58,8 +58,6 @@ The *Transaction Payload ID* is the [BLAKE2b-256](https://tools.ietf.org/html/rf

The following table describes the entirety of a _Transaction Payload_ in its serialized form following the notation from [TIP-21](../TIP-0021/tip-0021.md):

TODO what about inputs committments?

<table>
<tr>
<th>Name</th>
Expand Down Expand Up @@ -102,6 +100,13 @@ TODO what about inputs committments?
The unique value denoting whether the block was meant for mainnet, shimmer, testnet, or a private network. It consists of the first 8 bytes of the BLAKE2b-256 hash of the network name.
</td>
</tr>
<tr>
<td>Creation Time</td>
<td>uint64</td>
<td>
The slot index of the block in which the transaction was created.
</td>
</tr>
<tr>
<td>Inputs Count</td>
<td>uint16</td>
Expand Down Expand Up @@ -288,6 +293,9 @@ It is a unique value denoting whether the transaction was meant for the IOTA mai
| `testnet-1` | `1856588631910923207` | - |
| `example-mynetwork` | `1967754805504104511` | - |

#### Creation Time
Transaction timestamp is now expressed with `Slot Index`, as there is no need for finer granularity. The validity of the transaction timestamp is checked in comparison with the `Block` timestamp. Therefore, it is performed at the level of semantic validation of a block, described in [TIP-0046](../TIP-0046/tip-0046.md).

#### Inputs

The `Inputs` field holds the inputs to consume in order to fund the outputs of the <i>Transaction Payload</i>. Currently, there are three types of input:
Expand All @@ -303,12 +311,15 @@ Each input must be accompanied by a corresponding <i>Unlock</i> at the same inde
A <i>UTXO Input</i> is an input which references an unspent output of a previous transaction. This UTXO is uniquely identified by its _Output ID_, defined by the _Transaction ID_ of the creating transaction together with corresponding output index. Each <i>UTXO Input</i> must be accompanied by an <i>Unlock</i> that is allowed to unlock the referenced output.

##### Commitment Input
A _Commitment Input_ is an input that allows to reference commitment to a certain slot. It is used to provide the VM with the necessary context information from the node. It is used to prove that the time at the transaction execution is past certain slot in the past, as it indicates that the slot has been already committed.

A _Commitment Input_ is an input that allows to reference commitment to a certain slot. It is used to provide the VM with the necessary context information from the node, to prove that the time at the transaction execution is past certain slot in the past, as it indicates that the slot has been already committed. It is expressed as the _CommitmentID_ and can be resolved to the _Commitment_ value before it enters the VM. The _Commitment_ itself provides the `Slot Index` which serves as a time reference.

##### Block Issuance Credits Input
A _Block Issuance Credits Input_ is an input that allows to provide the VM with context for the value of the BIC vector for a specific slot. It is necessary information needed for destroying an _Account Output_, as it can be allowed only if the BIC balance is not negative at specific point in time.
A _Block Issuance Credits Input_ is an input that allows to provide the VM with context for the value of the BIC vector for a specific slot. It is necessary information needed for any _Account_ transitions, and account destroying. As any operation on the _Account_ can only be allowed if the BIC balance is not negative at specific point in time. _Block Issuance Credits Input_ is defined as follows. The input commitment will be resolved to hte `AccountID`, `CommitmentID` which contains the SLot Index and the BIC vector value for the given `AccountID` and `Slot Index`.

| Field Name | Type Value |
|--------------|------------|
| Account ID | ByteArray[32] |
| CommitmentID | ByteArray[32] |
#### Inputs Commitment

The `Inputs Commitment` field of the _Transaction Essence_ is a cryptographic commitment to the content of the consumed outputs (inputs). It consists of the BLAKE2b-256 hash of the concatenated output hashes.
Expand All @@ -327,6 +338,10 @@ The following table lists all the output types that are currently supported as w
| Account | 4 | [TIP-42](../TIP-0042/tip-0042.md#account-output) |
| Foundry | 5 | [TIP-44](../TIP-0044/tip-0044.md#foundry-output) |
| NFT | 6 | [TIP-43](../TIP-0043/tip-0043.md#nft-output) |
#### Allotments
The `Allotments` field contains the list of all mana allotments, the `Account ID` and corresponding values, that converts mana provided by the inputs in form of stored UTXO mana in inputs or potential mana derived from inputs' IOTA tokes. Mana listed in this field will be added on the slot commitment, in form of _Block Issuance Credits_ to the BIC vector of the slot that the transaction is issued in.

Note that _Block Issuance Credits_ are used to pay for the block issuance, they are burned on the slot commitment of the issuance slot. The good practice would be to always allot enough mana to cover for the block issuance.

#### Payload

Expand All @@ -346,9 +361,9 @@ The following table lists all the output types that are currently supported as w

| Unlock Name | Type Value | TIP |
|-------------|------------|--------------------------------------------------------------|
| Signature | 0 | [TIP-38](#signature-unlock) |
| Reference | 1 | [TIP-38](#reference-unlock) |
| Account | 2 | [TIP-18](../TIP-0042/tip-0042.md#account-locking--unlocking) |
| Signature | 0 | [TIP-45](#signature-unlock) |
| Reference | 1 | [TIP-45](#reference-unlock) |
| Account | 2 | [TIP-42](../TIP-0042/tip-0042.md#account-locking--unlocking) |
| NFT | 3 | [TIP-43](../TIP-0043/tip-0043.md#nft-locking--unlocking) |

#### Signature Unlock
Expand Down Expand Up @@ -460,6 +475,7 @@ The following criteria defines whether a payload passes the syntactical validati
* Essence:
* `Transaction Type` value must denote a _TIP-45 Transaction Essence_.
* `Network ID` must match the value of the current network.
* `CreationTime` must be a valid `Slot index` timestamp.
* Inputs:
* `Inputs Count` must be 0 < x ≤ `Max Inputs Count`.
* For each input the following must be true:
Expand All @@ -474,6 +490,10 @@ The following criteria defines whether a payload passes the syntactical validati
* The sum of all `Amount` fields must not exceed `Max IOTA Supply`.
* The sum of all `Mana Amount` field must not exceed `Max Mana Supply`.
* The count of all distinct native tokens present in outputs must not be larger than `Max Native Token Count`.
* Allottments:
* `Allottments Count` must be 0 < x ≤ `Max Allottments Count`.
* The sum of all `Mana` fields must not exceed `Max Mana Supply`.
* There must be no duplicated `AccountID`s in the list of allotments.
* Payload (if present):
* `Payload Type` must match one of the values described under [Payload](#payload).
* Payload fields must be correctly parsable in the context of the `Payload Type`.
Expand Down Expand Up @@ -530,17 +550,16 @@ where:

#### Semantic criteria for each output and all its output features in the context of the following input:
1. The _Transaction Payload_,
2. the list of UTXOs referenced by inputs and
3. / TDOD how to change that?: the Unix timestamp of the confirming milestone.
2. the list of UTXOs referenced by inputsF
* Each unlock must be valid with respect to the UTXO referenced by the input of the same index:
* If it is a _Signature Unlock_:
* The `Signature Type` must match the `Address Type` of the UTXO,
* the BLAKE2b-256 hash of `Public Key` must match the `Address` of the UTXO and
* the `Signature` field must contain a valid signature for `Public Key`.
* If it is a _Reference Unlock_, the referenced _Signature Unlock_ must be valid with respect to the UTXO.
* If it is an _Alias Unlock_:
* The address unlocking the UTXO must be an _Alias Address_.
* The referenced _Unlock_ unlocks the alias defined by the unlocking address of the UTXO.
* If it is an _Account Unlock_:
* The address unlocking the UTXO must be an _Account Address_.
* The referenced _Unlock_ unlocks the account defined by the unlocking address of the UTXO.
* If it is an _NFT Unlock_:
* The address unlocking the UTXO must be a _NFT Address_.
* The referenced _Unlock_ unlocks the NFT defined by the unlocking address of the UTXO.
Expand All @@ -551,16 +570,7 @@ Transactions that do not pass semantic validation are ignored. Their UTXOs are n

## Miscellaneous

### Transaction timestamps

Since transaction timestamps – whether they are signed or not – do not provide accuracy guarantee, the time of the trnsaction is defined by the `slot index`, as no more detailed time granularity is needed.
The correctness of the timespams is indirectly restricted by the Fishing condition, which does not allowto reference blocks that are `Fishing threshold` older than latest confirmed block. This rule puts restrictions on the block timestamp. Which in turn, is used to validate the transaction creation slot:
* The transaction creation slot must be less than or equal to the current slot index,
* transaction slot must be less or equal to the encapsulation block timestamp.

### Address reuse
// todo is this valid?

While, in contrast to Winternitz one-time signatures (W-OTS), producing multiple Ed25519 signatures for the same private key and address does not decrease its security, it still drastically reduces the privacy of users. It is thus considered best practice that applications and services create a new address per deposit to circumvent these privacy issues.

In essence, Ed25519 support allows for smaller transaction sizes and to safely spend funds which were sent to an already used deposit address. Ed25519 addresses are not meant to be used like email addresses. See this [Bitcoin wiki article](https://en.bitcoin.it/wiki/Address_reuse) for further information.
Expand Down

0 comments on commit 9c9af7c

Please sign in to comment.