diff --git a/tips/TIP-0019/assets/deposit_iota_AliasOutput_(max_functionality).jpg b/tips/TIP-0019/assets/deposit_iota_AliasOutput_(max_functionality).jpg
new file mode 100644
index 000000000..400530c87
Binary files /dev/null and b/tips/TIP-0019/assets/deposit_iota_AliasOutput_(max_functionality).jpg differ
diff --git a/tips/TIP-0019/assets/deposit_iota_AliasOutput_(min_functionality).jpg b/tips/TIP-0019/assets/deposit_iota_AliasOutput_(min_functionality).jpg
new file mode 100644
index 000000000..3fea3cd24
Binary files /dev/null and b/tips/TIP-0019/assets/deposit_iota_AliasOutput_(min_functionality).jpg differ
diff --git a/tips/TIP-0019/assets/deposit_iota_BasicOutput_(max_functionality).jpg b/tips/TIP-0019/assets/deposit_iota_BasicOutput_(max_functionality).jpg
new file mode 100644
index 000000000..80d8403b7
Binary files /dev/null and b/tips/TIP-0019/assets/deposit_iota_BasicOutput_(max_functionality).jpg differ
diff --git a/tips/TIP-0019/assets/deposit_iota_BasicOutput_(min_functionality).jpg b/tips/TIP-0019/assets/deposit_iota_BasicOutput_(min_functionality).jpg
new file mode 100644
index 000000000..f3040b8ae
Binary files /dev/null and b/tips/TIP-0019/assets/deposit_iota_BasicOutput_(min_functionality).jpg differ
diff --git a/tips/TIP-0019/assets/deposit_iota_FoundryOutput_(max_functionality).jpg b/tips/TIP-0019/assets/deposit_iota_FoundryOutput_(max_functionality).jpg
new file mode 100644
index 000000000..9e695a895
Binary files /dev/null and b/tips/TIP-0019/assets/deposit_iota_FoundryOutput_(max_functionality).jpg differ
diff --git a/tips/TIP-0019/assets/deposit_iota_FoundryOutput_(min_functionality).jpg b/tips/TIP-0019/assets/deposit_iota_FoundryOutput_(min_functionality).jpg
new file mode 100644
index 000000000..18ff8253a
Binary files /dev/null and b/tips/TIP-0019/assets/deposit_iota_FoundryOutput_(min_functionality).jpg differ
diff --git a/tips/TIP-0019/assets/deposit_iota_NFTOutput_(max_functionality).jpg b/tips/TIP-0019/assets/deposit_iota_NFTOutput_(max_functionality).jpg
new file mode 100644
index 000000000..915608810
Binary files /dev/null and b/tips/TIP-0019/assets/deposit_iota_NFTOutput_(max_functionality).jpg differ
diff --git a/tips/TIP-0019/assets/deposit_iota_NFTOutput_(min_functionality).jpg b/tips/TIP-0019/assets/deposit_iota_NFTOutput_(min_functionality).jpg
new file mode 100644
index 000000000..4163c79fb
Binary files /dev/null and b/tips/TIP-0019/assets/deposit_iota_NFTOutput_(min_functionality).jpg differ
diff --git a/tips/TIP-0019/assets/deposit_miota_AliasOutput_(max_functionality).jpg b/tips/TIP-0019/assets/deposit_miota_AliasOutput_(max_functionality).jpg
deleted file mode 100644
index b16e1381f..000000000
Binary files a/tips/TIP-0019/assets/deposit_miota_AliasOutput_(max_functionality).jpg and /dev/null differ
diff --git a/tips/TIP-0019/assets/deposit_miota_AliasOutput_(min_functionality).jpg b/tips/TIP-0019/assets/deposit_miota_AliasOutput_(min_functionality).jpg
deleted file mode 100644
index 3bf5ddcec..000000000
Binary files a/tips/TIP-0019/assets/deposit_miota_AliasOutput_(min_functionality).jpg and /dev/null differ
diff --git a/tips/TIP-0019/assets/deposit_miota_BasicOutput_(max_functionality).jpg b/tips/TIP-0019/assets/deposit_miota_BasicOutput_(max_functionality).jpg
deleted file mode 100644
index aa14e244c..000000000
Binary files a/tips/TIP-0019/assets/deposit_miota_BasicOutput_(max_functionality).jpg and /dev/null differ
diff --git a/tips/TIP-0019/assets/deposit_miota_BasicOutput_(min_functionality).jpg b/tips/TIP-0019/assets/deposit_miota_BasicOutput_(min_functionality).jpg
deleted file mode 100644
index 4c55672c9..000000000
Binary files a/tips/TIP-0019/assets/deposit_miota_BasicOutput_(min_functionality).jpg and /dev/null differ
diff --git a/tips/TIP-0019/assets/deposit_miota_FoundryOutput_(max_functionality).jpg b/tips/TIP-0019/assets/deposit_miota_FoundryOutput_(max_functionality).jpg
deleted file mode 100644
index d92c6e766..000000000
Binary files a/tips/TIP-0019/assets/deposit_miota_FoundryOutput_(max_functionality).jpg and /dev/null differ
diff --git a/tips/TIP-0019/assets/deposit_miota_FoundryOutput_(min_functionality).jpg b/tips/TIP-0019/assets/deposit_miota_FoundryOutput_(min_functionality).jpg
deleted file mode 100644
index 8c62c9bcb..000000000
Binary files a/tips/TIP-0019/assets/deposit_miota_FoundryOutput_(min_functionality).jpg and /dev/null differ
diff --git a/tips/TIP-0019/assets/deposit_miota_NFTOutput_(max_functionality).jpg b/tips/TIP-0019/assets/deposit_miota_NFTOutput_(max_functionality).jpg
deleted file mode 100644
index caf59f15d..000000000
Binary files a/tips/TIP-0019/assets/deposit_miota_NFTOutput_(max_functionality).jpg and /dev/null differ
diff --git a/tips/TIP-0019/assets/deposit_miota_NFTOutput_(min_functionality).jpg b/tips/TIP-0019/assets/deposit_miota_NFTOutput_(min_functionality).jpg
deleted file mode 100644
index c83c40357..000000000
Binary files a/tips/TIP-0019/assets/deposit_miota_NFTOutput_(min_functionality).jpg and /dev/null differ
diff --git a/tips/TIP-0019/assets/microtransactions_pt3_layer1.png b/tips/TIP-0019/assets/microtransactions_pt3_layer1.png
index 561db0bb1..da1bd7d6b 100644
Binary files a/tips/TIP-0019/assets/microtransactions_pt3_layer1.png and b/tips/TIP-0019/assets/microtransactions_pt3_layer1.png differ
diff --git a/tips/TIP-0019/assets/microtransactions_pt3_layer1.svg b/tips/TIP-0019/assets/microtransactions_pt3_layer1.svg
new file mode 100644
index 000000000..fbbf22aa4
--- /dev/null
+++ b/tips/TIP-0019/assets/microtransactions_pt3_layer1.svg
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/tips/TIP-0019/assets/microtransactions_pt3_layer2.png b/tips/TIP-0019/assets/microtransactions_pt3_layer2.png
index 67a46901d..0e5c95862 100644
Binary files a/tips/TIP-0019/assets/microtransactions_pt3_layer2.png and b/tips/TIP-0019/assets/microtransactions_pt3_layer2.png differ
diff --git a/tips/TIP-0019/assets/microtransactions_pt3_layer2.svg b/tips/TIP-0019/assets/microtransactions_pt3_layer2.svg
new file mode 100644
index 000000000..04131d708
--- /dev/null
+++ b/tips/TIP-0019/assets/microtransactions_pt3_layer2.svg
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/tips/TIP-0019/tip-0019.md b/tips/TIP-0019/tip-0019.md
index b80a46ba6..7f7b62d32 100644
--- a/tips/TIP-0019/tip-0019.md
+++ b/tips/TIP-0019/tip-0019.md
@@ -16,11 +16,11 @@ replaces: TIP-15
The current `dust protection` in `chrysalis-pt2` is only an intermediate solution to prevent attacks or misbehavior that could bloat the ledger database. The design has several drawbacks, e.g. it does not scale, relies on a total ordering of the tangle and it is rather complicated to use from a user point of view.
-This document describes a new `dust protection` concept, called `storage deposit`, which solves the mentioned drawbacks and creates a monetary incentive to keep the ledger state small. It focuses on the underlying problem, the increase in database size, instead of artificially limiting the number of UTXOs. This is achieved by enforcing a minimum IOTA coin deposit in every output based on the actually used disc space of the output itself.
+This document describes a new `dust protection` concept, called `storage deposit`, which solves the mentioned drawbacks and creates a monetary incentive to keep the ledger state small. It focuses on the underlying problem, the increase in database size, instead of artificially limiting the number of UTXOs. This is achieved by enforcing a minimum micros deposit in every output based on the actually used disc space of the output itself.
## Motivation
-In a distributed ledger network, every participant, a so-called node, needs to keep track of the current ledger state. Since `chrysalis-pt2`, the IOTA ledger state is based on the UTXO model, where every node keeps track of all the currently unspent outputs. Without `dust protection`, even outputs containing only one single IOTA coin are valid and therefore stored in the database.
+In a distributed ledger network, every participant, a so-called node, needs to keep track of the current ledger state. Since `chrysalis-pt2`, the IOTA ledger state is based on the UTXO model, where every node keeps track of all the currently unspent outputs. Without `dust protection`, even outputs containing only one single micro are valid and therefore stored in the database.
Misusage by honest users or intentionally bad behavior by malicious actors can lead to growing database and snapshot sizes and increasing computational costs (database lookups, balance calculations). Due to these increasing hardware requirements, the entry barrier to participate in the network becomes unaffordable and less nodes would operate the network.
@@ -46,13 +46,13 @@ Therefore, a new transaction validation rule is introduced which replaces the fo
Blocks including payloads, even transaction payloads, are considered to be pruned by the nodes, but unspent transaction outputs must be kept until they are spent. Therefore the `dust protection` is based on the unspent outputs only.
-**Every output created by a transaction needs to have at least a minimum amount of IOTA coins deposited in the output itself, otherwise the output is syntactically invalid.**
+**Every output created by a transaction needs to have at least a minimum amount of micros deposited in the output itself, otherwise the output is syntactically invalid.**
min_deposit_of_output = βv_byte_cost Β· v_byteβ
v_byte = β(weightπ Β· byte_sizeπ) + offset
where:
-- v_byte_cost: costs in IOTA coins per virtual byte
+- v_byte_cost: costs in micros per virtual byte
- weightπ: factor of field π that takes computational and storage costs into account
- byte_sizeπ: size of field π in bytes
- offset: additional v_bytes that are caused by additional data that has to be stored in the database but is not part of the output itself
@@ -71,7 +71,7 @@ This is not a fee, because the deposited coins can be reclaimed by consuming the
The proposed solution has several advantages over the former solution.
-First of all, the database size is limited to an absolute maximum size. Since the total supply of IOTA coins stays constant, also the maximum amount of `v_bytes` that can ever be written to the database remains constant.
+First of all, the database size is limited to an absolute maximum size. Since the total supply of micros stays constant, also the maximum amount of `v_bytes` that can ever be written to the database remains constant.
Total ordering of the tangle is not necessary because there is no shared global ledger state for transaction validation anymore. The node can determine if the transaction is valid and the dust protection rules are fulfilled, just by looking at the transaction itself. Therefore this solution is also suitable for IOTA 2.0.
@@ -81,7 +81,7 @@ Users have an economic incentive to clean up the database. By consuming old unus
### Drawbacks
-This solution prevents seamless microtransactions, which are a unique selling point for IOTA, because the issuer of the transaction always needs to deposit `min_deposit_of_output` IOTA coins in the output created by the transaction. This minimum deposit will have a higher value than the microtransaction itself, which basically makes microtransactions impossible. Two different solutions to circumvent this obstacle are introduced [here](#Microtransactions).
+This solution prevents seamless microtransactions, which are a unique selling point for IOTA, because the issuer of the transaction always needs to deposit `min_deposit_of_output` micros in the output created by the transaction. This minimum deposit will have a higher value than the microtransaction itself, which basically makes microtransactions impossible. Two different solutions to circumvent this obstacle are introduced [here](#Microtransactions).
### How does it affect other parts of the protocol?
@@ -90,15 +90,15 @@ However, all output types like e.g. smart contract requests are affected and mus
### Byte cost calculations
-To limit the maximum database size, the total IOTA supply needs to be divided by the target database size in bytes to get the worst case scenario regarding the byte costs.
+To limit the maximum database size, the total micros supply needs to be divided by the target database size in bytes to get the worst case scenario regarding the byte costs.
-However, in this scenario no outputs hold more IOTA coins than required for the `dust protection`. This does not represent the real distribution of funds over the UTXOs. We could assume that these output amounts follow Zipf's law. Unfortunately, fitting a Zipf distribution to the current ledger state will not match the future distribution of the funds for several reasons:
+However, in this scenario no outputs hold more micros than required for the `dust protection`. This does not represent the real distribution of funds over the UTXOs. We could assume that these output amounts follow Zipf's law. Unfortunately, fitting a Zipf distribution to the current ledger state will not match the future distribution of the funds for several reasons:
- There is already another `dust protection` in place, which distorts the distribution.
- With new use cases enabled by the new `dust protection` (e.g. tokenization, storing arbitrary data in the ledger), the distribution will dramatically change.
- Fittings for other DLT projects do not match because there are transaction fees in place, which decrease the amount of dust outputs in the distribution.
-Another possibility would be to estimate how much percentage of the database will be used for outputs with minimum required deposit (`fund sparsitiy percentage`) in the future. The remaining IOTA coins can be ignored in that case to simplify the calculation. Since a fund sparsity percentage of less than 20% would already be bad for other upcoming protocol features like the mana calculation, we could take this value for our calculation instead of the worst case.
+Another possibility would be to estimate how much percentage of the database will be used for outputs with minimum required deposit (`fund sparsitiy percentage`) in the future. The remaining micros can be ignored in that case to simplify the calculation. Since a fund sparsity percentage of less than 20% would already be bad for other upcoming protocol features like the mana calculation, we could take this value for our calculation instead of the worst case.
### Weights for different outputs
@@ -214,7 +214,7 @@ The following tables show the different outputs including the possible fields an
data
8
8
-
The amount of IOTA coins held by the output.
+
The amount of micros held by the output.
Native Tokens Count
@@ -495,7 +495,7 @@ The following tables show the different outputs including the possible fields an
8
8
- Amount of IOTA coins the consuming transaction should deposit to the address defined in Return Address.
+ Amount of micros the consuming transaction should deposit to the address defined in Return Address.
@@ -878,9 +878,9 @@ The following tables show the different outputs including the possible fields an
-.jpg)
+.jpg)
-.jpg)
+.jpg)
@@ -957,7 +957,7 @@ The following tables show the different outputs including the possible fields an
data
8
8
-
The amount of IOTA coins held by the output.
+
The amount of micros held by the output.
Native Tokens Count
@@ -1613,9 +1613,9 @@ The following tables show the different outputs including the possible fields an
@@ -2054,7 +2054,7 @@ The following tables show the different outputs including the possible fields an
data
8
8
-
The amount of IOTA coins held by the output.
+
The amount of micros held by the output.
Native Tokens Count
@@ -2342,7 +2342,7 @@ The following tables show the different outputs including the possible fields an
8
8
- Amount of IOTA coins the consuming transaction should deposit to the address defined in Return Address.
+ Amount of micros coins the consuming transaction should deposit to the address defined in Return Address.
@@ -2890,9 +2890,9 @@ The following tables show the different outputs including the possible fields an
-.jpg)
+.jpg)
-.jpg)
+.jpg)
### Microtransactions
@@ -2903,7 +2903,7 @@ To enable microtransactions on Layer 1 and still satisfy the `min_deposit_of_out
-The preceding picture shows the process of the `conditional sending` mechanism. Alice uses the `Basic Output` to send a microtransaction of 1 IOTA to Bob's `Address`. To fulfill the `min_deposit_of_output` requirement, the `Amount` is increased by `min_deposit_of_output` IOTA, which is 1 MIOTA in the above example. To prevent Bob from accessing these additional funds called the `storage deposit`, Alice adds the optional `Storage Deposit Return Unlock Condition` to the `Basic Output`. Now Bob can only consume the newly created output, if the unlocking transaction deposits the specified `Return Amount` IOTA coins, in this case 1 MIOTA, to the `Return Address` value defined by Alice. By consuming another UTXO and adding its amount to the received 1 IOTA, Bob takes care to create a valid output according to the dust protection rules.
+The preceding picture shows the process of the `conditional sending` mechanism. Alice uses the `Basic Output` to send a microtransaction of 1 micro to Bob's `Address`. To fulfill the `min_deposit_of_output` requirement, the `Amount` is increased by `min_deposit_of_output` micro, which is 1 IOTA in the above example. To prevent Bob from accessing these additional funds called the `storage deposit`, Alice adds the optional `Storage Deposit Return Unlock Condition` to the `Basic Output`. Now Bob can only consume the newly created output, if the unlocking transaction deposits the specified `Return Amount` micros, in this case 1 IOTA, to the `Return Address` value defined by Alice. By consuming another UTXO and adding its amount to the received 1 micro, Bob takes care to create a valid output according to the dust protection rules.
To prevent Bob from blocking access to the `storage deposit` forever, Alice specifies the additional `Expiration Unlock Condition` in the `Basic Output`. If Bob does not consume the output before the time window defined by Alice expires, Alice regains total control over the output.
@@ -2917,7 +2917,7 @@ Another solution is to outsource microtransactions to Layer 2 applications like
-In this example, Alice sends funds to a smart contract chain on Layer 1 with an output that covers at least `min_deposit_of_output`. From this point on, Alice can send any number of off-chain requests to the smart contract chain, causing the smart contract to send microtransactions from Alice' on-chain account to Bob's on-chain account. Bob can now request his on-chain account balances to be withdrawn to his Layer 1 address. The last step can also be combined with the formerly introduced `conditional sending` mechanism, in case Bob wants to withdraw less than `min_deposit_of_output` IOTA coins or native assets.
+In this example, Alice sends funds to a smart contract chain on Layer 1 with an output that covers at least `min_deposit_of_output`. From this point on, Alice can send any number of off-chain requests to the smart contract chain, causing the smart contract to send microtransactions from Alice' on-chain account to Bob's on-chain account. Bob can now request his on-chain account balances to be withdrawn to his Layer 1 address. The last step can also be combined with the formerly introduced `conditional sending` mechanism, in case Bob wants to withdraw less than `min_deposit_of_output` micros or native assets.
| :information_source: Potential additional mechanisms for microtransactions are currently being discussed. |
| --------------------------------------------------------------------------------------------------------- |