LNPBP-11, 12, 13: RGB public state transitions about lnpbps HOT 1 OPEN

Discussion notes

@dr-orlovsky> Schema defines which types of states exist. For instance, one “type of state” is “amount of asset” (but even for fungible assets there are more state types, like “right to re-issue” etc). State is a “digital right”, like ownership rights on the asset, or secondary issuance right etc. So under some schema there could be multiple types of state.

Schema and genesis define rules for validation of each state type, for instance for ownership right (=“amount of the asset” state) the rule is: “sum of inputs must be equal to sum of outputs”. For other rights the rule is different, for instance for the secondary issuance we need to validate that the sum of all issuances does not exceed the max supply from genesis.

Genesis assigns some state (of some type) to UTXOs, defining seals in the following way. Whoever owns the state=can spend that UTXO, owns the corresponding right and can assign a new state to new UTXO creating state transition.

^^^ For now, this is just terminology of current RGB w/o the proposed change

Now, lets imagine that the contract creator, in genesis (if the schema allows it) says “anybody who can prove that he has locked bitcoins to this specific multisig can issue equivalent amount of the asset of this type”. This is a validation rule for some specific state type.

However, the question here is who has the right to do this issuance? This kind of issuance is not a state, since it can’t be bound to a specific UTXO: the right is “public”, meaning “anyone can do it” (of course they still need to follow the validation rules). So this is not a single-use-seal or state, and we name this thing “valency”: it is an extension point, where anyone can add something to the contract (again, under the fixed validation rules defined by schema/genesis).

So, any party can use that valency by creating a special data structure, which, like genesis (but it’s not genesis!), does not require to be committed into the blockchain (since it does not close any seals). This data structure is called “extension”.

Again, similar to genesis, this data structure can define a set of seals with some state (only of types and in amounts allowed by the schema) and assign that state to UTXOs (providing necessary proofs, suck as proofs of bitcoins being locked, as a part of metadata).

Next, those who are willing to accept this “issued” tokens just spend those UTXOs (validating the extension and genesis), creating a normal state transition, and the further process goes as usual.

In “ethereum terms”, valencies are “contract methods”, which can be called by anybody, with values for the method parameters stored in the metadata fields, creating extension (equivalent of ethereum contract-call type of transaction).

All that extension does is creating seals. So you use an extension when you spend that UTXO from that seal, and you either lose that state/invalidate that extension, or commit to the state transition referencing that extension in the spending transaction, and if you do the latter, you need to validate that extension against schema & genesis rules (otherwise new owners will not accept your proofs).

Once you define a seal, the rest always works in the same way for all three things: genesis, transitions and now extensions: there must be no vulnerabilities, b/c the validation procedure is always the same.

It does not require any changes in the validation logic (it extends the verification against schema rules with new rules, but not the commitment structure validation or scripting).

——
In other words, the proposal allows the contract creator to extend the right of defining new single-use-seals not just to those who are already a part of the contract (i.e. owns some state/asset on their UTXO), but also to publicity. Nevertheless, this publicity, whenever it uses that right, should stick to certain procedure, otherwise the created state (and seals) would be unusable.

@fedsten > Let me see if I understood correctly with a practical example:

1. Alice issues a new token with a schema that defines some state, and an extension point that defines how others can freely create a new seal separated from the transaction graph originating from her seal.
2. Later on Bob creates a new seal that points to the extension point of Alice's contract, providing proof that the condition defined in the extension point are met (eg he locked some bitcoins in a multisig).
3. Carol receives some tokens from Bob, and she verifies that Bob has indeed met the condition defined in Alice's contract to consider the state transition as valid.

@dr-orlovsky> Correct

@fedsten > Could Bob also include another extension point in his new seal? Would this be something forbidden by default or required to be defined in Alice's contract?

@dr-orlovsky > You are mixing seals with graph nodes (state transitions/extensions/genesis). Each node can define multiple seals of multiple types.
'Node <-one to many-> Seal type <-one to many-> Seal definition' - this is the real data structure, so extension points are parts of nodes, but not parts of seals. Maxim Orlovsky, [6 Oct 2020, 17:46:23]:
To explain it a bit: with the fungible asset schema I can create a state transition spending the “secondary issuance” seal/UTXO, and this state transition will define:

1. one seal of “secondary issuance” type (for future issuances)
2. multiple seals of “asset” type (which will hold assets created during this issuance).
   [it’s all with normal RGB]

Now, coming back to your question. Yes, state transitions may also have extension points, but only if a schema allows it.

• State transition uses ancestors to reference state & seals defined by some previous node (as a part of assignments);
• Extension node uses ancestors to reference valencies (=extension points) of a previous node (genesis, state transition or other extension).

@fedsten > So basically any new state may derive by either a seal that got unsealed, or an open valency that defined some conditions?

@dr-orlovsky > Yes, such usage is possible. Actually it opens a lot of different use cases (especially those completely outside of asset/token world), impossible with RGB before this concept was been introduced. If you think of a single-use-seal as of a digital right with a clear owner (“owned right”) and possible additional data/state, and of an extension point as a publically-available digital right (“public right”), with complex rules and conditions you can apply for their further evolution with schema and simplicity scripting… This is actually mind blowing what can be done with it (up to building trustless legal systems with economical enforcements for P2P & anonymous parallel digital economy). Also this is very scalable: extensions are ephemeral and their creation does not require a bitcoin transaction.

from lnpbps.