TIP-18 Multi-Asset Ledger and ISC Support #38

lzpap · 2021-11-04T14:23:20Z

Description

This TIP describes new output types, furthermore updated transaction structure and validation logic.

Rendered Version

Linked RFCs

Byte Cost Based Dust Protection

text/0038-output-types-for-tokenization-and-sc/0038-output-types-for-tokenization-and-sc.md

PhilippGackstatter

Unix timestamps should probably be uint64 for future proofing.

text/0038-output-types-for-tokenization-and-sc/0038-output-types-for-tokenization-and-sc.md

Do not use reserved output type numbers from chpt2.

…es-for-tokenization-and-sc.md Co-authored-by: Thoralf-M <[email protected]>

Output can be unlocked if time is equal or past the timelock.

nicole-obrien · 2022-06-20T12:56:52Z

tips/TIP-0018/tip-0018.md

+###### Additional syntactic transaction validation rule:
+
+- `Minimum Storage Deposit` is the storage deposit in the base currency required for a <i>Basic Output</i> that only
+  has an <i>Address Unlock Condition</i> with `Return Address`, no additional unlock conditions, no features and
+  no native tokens.
+- It must hold true, that `Minimum Storage Deposit` ≤  `Return Amount` ≤ `Amount`.
+
+###### Additional semantic transaction validation rule:
+
+- An output that has <i>Storage Deposit Return Unlock Condition</i> specified must only be consumed and unlocked in a
+  transaction that deposits `Return Amount` IOTA coins to `Return Address` via one or more outputs that:
+   - are of type [<i>Basic Output</i>](#basic-output),
+   - have only an [<i>Address Unlock Condition</i>](#address-unlock-condition) defined, and
+   - have no [<i>Features</i>](#features).
+- When several outputs with <i>Storage Deposit Return Unlock Condition</i> and the same `Return Address` are consumed,
+  their return amounts per `Return Addresses` are summed up and the output side of the transaction must deposit
+  _at least_ this total sum per `Return Address` via output(s) that satisfy the previous condition.


I am curious why the output unlocking the Storage Deposit Return Unlock Condition, has such strict syntactic and semantic validation rules. It appears to me that the only forced rule should be that the returning output can not also have a Storage Deposit Return Unlock Condition as not to create a chain of them.

I think it would be great for the user to be able to return the incoming output in its entirety to the sender if they wish to, even if they don't have extra funds to cover the storage deposit themselves.

There are several considerations, namely:

We don't allow additional unlock conditions because then you could attack the sender easily. Imagine you send back the deposit with a timelock in 10 years, or with an expiration in the past to your address. The sender loses the deposit in these cases, while the point of the SDRUC is not to lose it in any case.

Features don't affect the unlocking so we could theoretically allow them. If you used the SDRUC however, it means you want to send something which is less than the storage deposit, or its a native token. So if the recipient wants to return it with features, they have to pay into the output since features increase the storage deposit.

We defined the returns as basic outputs since aliases and foundries might have complicated oenwership and don't support the Address Unlock Condition. If you really wanted we could also allow NFTs with only an Address Unlock Condition, but does it make sense?

Back to your original question: you want to make it so that a user without funds can return the output with SDRUC. You can do that now with basic outputs, can't you?

I get a basic output with SDRUC, which says I must return X tokens to Return Address. The output itself has X+Y tokens.

notice, that the spec says the transaction must deposit at least this total sum per Return Address via output(s) that satisfy the previous condition

So even if you don't have funds in your wallet, you can satisfy the SDRUC unlock conditions if you send back a basic output with X+Y tokens to return address. (btw in practce I think the reciever would just pocket Y tokens for themselves)

We don't allow additional unlock conditions

Ah yes I meant to write this, I agree that you shouldn't have allow unlock conditions.

Features don't affect the unlocking so we could theoretically allow them.

This is what I think we shouldn't limit

If you used the SDRUC however, it means you want to send something which is less than the storage deposit, or its a native token. So if the recipient wants to return it with features, they have to pay into the output since features increase the storage deposit.

If the original output (with the SDRUC) had features then it would have contained enough IOTA to cover the storage deposit, hence you can inherently send it back without needing to add any of your own.

If the original output didn't have features then yes you may need to provide more IOTA to cover the storage deposit, but thats up to the sender to decide, I don't think we should limit too much what could be a valid UTXO.

If you really wanted we could also allow NFTs with only an Address Unlock Condition, but does it make sense?

Yes I think it makes sense to be able to return an NFT it your don't want it. And again its the freedom of the option to do this, as I don't see a technical limitation of allowing it.

So even if you don't have funds in your wallet, you can satisfy the SDRUC unlock conditions if you send back a basic output with X+Y tokens to return address. (btw in practice I think the receiver would just pocket Y tokens for themselves)

The receiver couldn't pocket the tokens if they couldn't provide the amount to satisfy the unlock.

tips/TIP-0018/tip-0018.md

Fix extra space Co-authored-by: Luca Moser <[email protected]>

Co-authored-by: Luca Moser <[email protected]>

tips/TIP-0018/tip-0018.md

Co-authored-by: Thoralf-M <[email protected]>

Table had reverse logic

Thoralf-M reviewed Nov 6, 2021

View reviewed changes