TIP-38: Building Blocks for IOTA 2.0 Output Types

[PhilippGackstatter]

Rendered Version

Note that:

• This TIP is in Draft mode and as such is still being updated.
• Links to other new TIPs don't work and will only work once the TIP is merged.

[thibault-martinez]

It is not very clear if something is omitted because it's contextual (like ImplicitAccountCreationAddress only being allowed in Basic outputs) or because it simply is disallowed (like I assume ImplicitAccountCreationAddress is in StorageDepositReturn and Expiration?).

[thibault-martinez]

So maybe put an explicit note in StorageDepositReturn and Expiration that ImplicitAccountCreationAddress is disallowed or in TIP 42 be a bit more explicit that it can only be used in an AddressUnlockCondition.

[thibault-martinez]

Ignore me if it's said already somewhere, may have missed it.

[PhilippGackstatter]

It's tricky to express this correctly here where Address UC is generically defined, because it suggest that this always is the schema of an Address UC, which is a reasonable assumption given that it's true for every other schema.

Every output currently expresses which address is allowed in its Address UC (Basic allows Impliciti Acc Creation Addresses while others don't).

• One option is to omit the addresses here and adding a note that each output specifies which addresses it allows.
• Another one is to only include the ones that are always allowed to be present and add a note that each occurence of the Address UC can specify additional ones or something along those lines. Basically how it is now, minus the note.

I think I like the latter one more because it doesn't break the schema definitions as much as the other one and every other schema can be left as-is.

[thibault-martinez]

Ok but if we do that, it means that I have to look at ALL tips to see if something is allowed or not. Like, how do I come to the conclusion whether ImplicitAddress is allowed in a StorageDeposit or Expiration? If it just doesn't make sense to start with, I would put a note in this TIP.

[PhilippGackstatter]

I'd say you can come to the conclusion that Implicit Account Creation Address it not allowed in the SDRUC because it's not in the SDRUC schema and there's no note that occurences of the SDRUC may change that.
Conversely, for Address UC I would add such a note.

I know it's somewhat implicit that way, but it's also not sensible to add a note to every schema that no changes are allowed to it. So in essence, I'd make the changes opt-in by adding a note (like for Addres UC).

Does that sound reasonable?