Standard RGB interfaces v1 RC1

[dr-orlovsky]

This updates all standard RGB interfaces to v0.10 requirements and capabilities, finalizing them as an initial standard for asset issuance.

All future versions will be additive, encoded as a part of the interface name in form of "RGB20rev1" etc.

Summary of the changes:

• All data types shared by different interfaces are put into RGBContracts data type library, which is now a part of standard LNPBP-31

• Decentralized issuance removed from RGB20 and RGB21 and moved to independent interface RGB30.

  Rationale: most of assets would be either centrally or decentralizable issued; mixing these two schemata in the single interface makes verification and state computation hard. If a contract supports both variants, it can just implement both interfaces (or provide a custom interface).

• Asset tickers will use only upper-case letters and digits; other characters are prohibited

• MIME types renamed to MediaType (as defined by RFC standard) and are not composed according to RFC requirements

• Decentralized issuance in RGB20 uses valencies and state extensions (which were omitted previously)

• RGB20 and RGB21 issuance may now include reserves (pointers to UTXOs with locked-in bitcoins + proofs of the lock)

• Added genesis interfaces (were absent before, but must be defined as a part of the RGB stdlib interface in v0.10)

• All operations are now capitalized and state types camelCased.

  Rationale:

  • To distinguish state types from data types (which are always uppercase)
  • To distinguish operations from state type names
  • To use the same case convention in JSON/YAML contract definitions (previously capitalized state types were dissonant with the rest of JSON/YAML keys, which are in camelCase)

[cryptoquick]

So, one thing that still bothers me is the inability to specify a IDs for owner, creator, and parent. I realize assetOwner here is with reference to a UTXO, but that's highly ephemeral. With an accounts-based system, the account address is often used as a proxy for DID, but Bitcoin discourages address reuse, and so we'll need to rely on something like RGB22 for attribution, since we can't rely on on-chain ownership records, either. And attribution is very, very necessary for proving the value of an NFT. Things like provenance are useful, and so is proving a body of work is presented by a specific artist.

Some definitions:

• Owner: Identity of the present owner of the token. Mutable. Optional, can be left blank if privacy is desired.
• Creator: Can only be specified upon creation. Immutable / Global. Optional.
• Parent: A parent RGB ID to associate this with, to form DAG-like relationships. Mutable. Optional.
• Original Parent: Same as Parent, but immutable. Optional.

If implemented, they'd be pointers to an RGB ID (could be any other asset, including RGB22, RGB21, etc), and it'd be really useful if some of these fields could be optionally mutable (as indicated) against either the same UTXO that owns the asset, or a separate UTXO that can be spent in exclusion. This would allow the UDA to be dynamic, and an on-chain record of DID association could be updated with each transfer, ideally within the same state transition as the transfer consignment, and not as a separate on-chain commitment.

In addition, for Carbonado, it'd be very helpful if we could include a public key alongside the hash. This allows us to change relays should infrastructure change and the node carrying the hash is no longer available. This also helps us verify the signature of the file, and nodes generally namespace their files by pubkey, and encrypt files on-disk in a way that can only be decoded if the public key is specified. And most importantly, the blake3 hash is a keyed hash, for privacy, and so a public key is needed to verify the data once it's been retrieved. The keys we use are 33-byte compressed secp256k1 pubkeys. If we didn't have pubkeys, we'd need to build additional infrastructure to support keyless lookups.

Do all these things make sense?

[dr-orlovsky]

@cryptoquick @zoedberg @crisdut I put the changes we discussed during our dev call today - and commented some things which you need to be aware of.

[dr-orlovsky]

@crisdut can you pls also provide your full name and surname such that I can add you to the author list?

[crisdut]

@crisdut can you pls also provide your full name and surname such that I can add you to the author list?

Sure. The full name is Armando Dutra

[zoedberg]

@dr-orlovsky Sorry for reporting this only now but last time I completely forgot. Shouldn't we have a timestamp field for contracts? In v0.9 this was contract metadata.

[dr-orlovsky]

@zoedberg yep, good point!

However, an alternative might be that we can have a dedicated interface for reporting genesis timestamp (potentially also using OTS) for all schemata, including fungibles, NFTs etc.

What do you think? I had the similar idea for the issuer identity which may be a dedicated interface.

[zoedberg]

@zoedberg yep, good point!

However, an alternative might be that we can have a dedicated interface for reporting genesis timestamp (potentially also using OTS) for all schemata, including fungibles, NFTs etc.

What do you think? I had the similar idea for the issuer identity which may be a dedicated interface.

Not sure what do you mean, could you please explain more in detail how this interface should work? Sounds a bit complex and I'm not sure we should add more complexity just for the timestamp, but I'm probably missing what's the advantage of the solution you're proposing

[dr-orlovsky]

Answering @zoedberg

Not sure what do you mean, could you please explain more in detail how this interface should work?

Interfaces are composable, meaning that a contract may implement multiple interfaces. This leaves one question which approach is better to use: normal computer science (like in rust), where we use "atomic interfaces" for a bits of composable functionality - or "ethereum"-like where we put in a single interface everything what is needed for a holistic user case.

For instance, we may see the following atomic contract ABIs:

• ABI to retrieve name of a contract (and other metadata shared accross all contracts)
• ABI to retrieve information about the issuer (identity of the issuer), which can be also implemented by assets, NFTs, digital identity contracts and many others
• ABI to retrieve information about supply (shared between RGB20 and RGB21)
• other Fungible and NFT-specific ABIs

If each piece of the ABIs will be made an interface, a contract can select a set of interfaces to implement - and wallets will have more freedom in presenting unknown types of the contracts in the UI.

What I tend to think is that we need a third approach: interfaces should be atomic, but large-level interfaces like RGB20 etc should provide the whole set of functionality, meaning that a wallet must be able to decompose a high-level interface into interface atoms.

I.e., in binary form (and in consignment) there will be just one/very few high-level interfaces and implementation for a contract (let's say for fungibles it will be RGB20). However, for developers and wallets we will provide an ability to do the following:

interface NamedContract
   global name: String

interface RGB20 implements NamedContract

and wallets may test a contract on supporting these ABI atoms:

   let iface = stock.contract_iface(contract_id);
   if iface.supports(NamedContract::id()) {
      // present contract name in the UI
   }

[dr-orlovsky]

@zoedberg ok, I think the "complex interface" approach (like we currently have with RGB20) is correct - and the other two should not be used.

Rationale: a contract may expose both NFT and a token (even several of them) and they all may have different names. Thus, accessing them through a single "atomic ABI" is invalid.

[dr-orlovsky]

@zoedberg added timestamps to all interfaces in https://github.com/LNP-BP/LNPBPs/pull/154/commits/bdc4f926be012bed341deeb61d08f1af42445ffc

[dr-orlovsky]

Merging this - we already have many rounds of discussion here and all amendments seems to be fulfilled. If something is missed - feel free to open an issue or do another PR.