lnp-bp / presentations Goto Github PK

This issue is the enhancement of #12

RGB functionality is not dependent on Taproot deployment, though is already compatible with it.

However, RGB will benefit from Taproot, but it’s benefit is purely bitcoin-based benefit (i.e. indirect). Better multisigs, adaptor-based signatures protocols, LN improvements (PTLCs)

Internally inside RGB there is nothing to sign (so Schnorr's change nothing internally) and no use for Bitcoin script (so no use from the new Tapscript)

Assignment

Assignment is an owned right (defined by owned right type u8 value) + state data + UTXO, which forms a single-use-seal definition when it is assigned that owned right.

So: nothing can prevent some given UTXO from having multiple assignments, of different owned right type, and even for each owned right type there might be multiple assignments.

UTXO <-one to many-> owned right type <-one to many-> assignment of some state:

• assign an inflation right to it (one)
• assign ownership right fo 100 of USDT
• assign ownership right of 10 Apple shares under different contract
• assign ownership right of 10000 of USDT again

This is a very bad situation, but we can’t prevent it from happening.
Especially if you assign different types of owned rights under the same contract you may not be able to create a state transition without loosing some of the rights or assets (since state transitions have a very strict set of owned rights type for which they can close seals). That is why @dr-orlovsky has created “split rights" state transition, which does only one thing - gives the ability to split those mixed rights into different UTXOs.
Management of these UTXOs stays an opened question.

RGB Schema describes the actual requirements for the state transition validation outside of the level of Bitcoin script commitments. It allows simple updates without software modifications, so that wallets, explorers, LN nodes etc could accept new types of assets without any code changes.

What is being defined by RGB Schema?

• Types of state transitions
• Types of seals transitions
• Semantics for state and Simplicity scripts for validating the state
• Semantics for metadata
• Referenced Simplicity script modules
• Additional constraints on each type of state transition:
  • Which seals may be defined by the state transition
  • Which state may be associated with each seals
  • Which metadata is required, optional and prohibited
  • Which additional scripts and with which constraints may be defined

This issue is related to #14

RGB compared to Liquid Confidential Assets:

• Works with Lightning Network
• Replaces Large Borromean signatures range proofs with modern Bulletproofs
• No blockchain space consumption!
• Universal smart contract system
• Works on Bitcoin mainnet, does not require federation

RGB compared to OMNI/Colored coins/Counterparty

• No blockchain consumption
• Much higher privacy
• Works with LN without its modifications

RGB compared to Ethereum/EOS/other "corporate blockchains"

• RGB is NOT a blockchain!
• Works on and with Bitcoin: 
the only censorship-resistant unconfiscatable hard money

Omni BOLT compared to RGB LN

• Breaking BOLT message compatibility
• Breaking BOLT tx structure compatibility
• No backports from LND
• No TLV extensions
• Requires separate nodes for OMNI Bolt and Bitcoin LN
• Requires Omni Core backend, can't work with just Bitcoin Core

From my understanding of the proposed engraving and reserve features, both open the potential to interesting use cases.

Engraving sounds like a native way to enable async.art 's model of minting "master NFTs" which are composed of several "layer NFTs". Layer NFTs can be modified by owners which in turn alters the master NFT. The ability to collaborate on a single work seems to have found traction among the NFT art community - async.art recently set a record with their $120K sale for a single work (https://www.kogocrypto.com/micah-johnsons-nft-artwork-sells-for-120000-on-async-art/).

The reserve feature could be immediately useful to Scarce.City. Our first planned NFT use case is to associate tokens with physical art as a tokenized certificate of authenticity. Reserves could allow us to automatically and trustlessly transfer the token to the buyer of the physical work when they make a payment to a designated Bitcoin address.

I think these use cases are just scratching the surface of what these features enable.

There is nothing specific inside any LN node that allows their monetisation, it’s more about the Lightning Network itself and protocols where you have things like routing fee or where you can build services on top of the node which you can monetise with LN payments.
In this regard, the LNP Node is not different from any other nodes, so it can be monetised in the same way, as monetisation is not node-specific, but protocol-specific and specific to the end-user services that are implemented on top of the node by companies or users. 

However, outside of LNP Node, the LNP/BP Standards Association has been building a set of protocols that would add a lot of monetisation options to the LN itself. First protocol is RGB, which unlocks the functionality of DEX inside the Lightning Network, where LNP Node will allow you to act as a part of a DEX, with further extending the possibilities to create liquidity pools for different RGB assets. Next protocol is called Storm and is made (not fully implemented yet, but we already have required faucets ready) for storage and messaging, meaning that LNP Node can be a part of this storage provider and we will have an infrastructure around the node, which will allow different additional monetisation options not present in LN now.

• Data is known only to owners, not the whole world
• Amounts are confidential with Pedersen commitments and Bulletproofs, combining best from Liquid & Grin
• Merklization and partial data reveal keeps a lot of past history private even from future owners
• No RGB-specific data can be extracted from Bitcoin blockchain or Lightning channel transactions

• Fungible assets & securities (options, futures)
  • Centrally or federation-issued
  • Issued anonymously or publicly
  • With possible secondary issuance, demurrage, inflation, etc
• Different forms of bearer rights (voting etc)
• Non-fungible assets (tokenized art or game collectibles)
• Decentralized digital identity & key management
• Non-financial accounting systems: electricity, medical records etc

Yes. Actually, you can do DAO with Bitcoin, not even with RGB.
When we have Taproot, you can create a DAO with particular voting rights you want to have there (whatever they are), structure it as tapscript, assign digital assets/company rights to an output and have a proper DAO-like structure of arbitrary complexity on top of Bitcoin.

Create a folder where the visual materials for marketing, educational and presentation purposes will be stored

Create a folder where all the PDFs on RGB, Spectrum and other technologies included into the LNP/BP Association scope will be consolidated

1. Most part of RGB is relying on Bitcoin and Lightning safety on L1.
2. State isolation: state is isolated between different smart contracts and they can interact only through special protocols (Spectrum) inside channels.
3. Formal verification: contract properties can be proven with formal models.

It is not different in terms of implementing the Lightning Network specification, but it is very different in its architecture. It is created with the idea that we need an implementation that is flexible and that would allow you to easily add very complex modifications of the current Lightning Network so that you could get, for example, PTLC and DLC running, play with Taproot or channel factories. Due to a very rigid architecture of other LN nodes, any experiments become very complex and hard, often leading to the need of rewriting huge parts of nodes implementations in order to do it. With the LNP Node it is fairly easy to do (compared to rewriting existing nodes or writing your own from scratch).

• Confidentiality
• Safety
• Scalability
• No bitcoin blockchain congestion
• Future-ready without hardforks
• Higher censorship-resistance than in bitcoin: miners do not see that there is something going on with assets in transactions

It is organised into a branching tree that always start at genesis, so Vec may be an outdated representation. Basically, you create “inflation rights” at genesis, allocate each of them to some UTXO and specify how much of the inflation this branch may produce. Later, when this UTXO is spent, the issuer creates “inflation” type of state transition, where he specifies to where the newly issued asset is allocated + provides (if necessary) new inflation rights, one or several, such that their sum is equal to the current allowed inflation in the branch minus already issued assets.

Open question: what would be the best representation of that in both rust data structures and SQL tables?

RGB uses paradigm-based approach:

• Layer isolation via abstraction
• Layer interaction via strictly-defined interfaces
• No future hardforks, just a single release

Common development/coding architecture paradigms used for RGB:

• Strict encoding: LNPBP-6
• Single-use seals: LNPBP-7
• Cryptographic commitments: LNPBP-8
• Client-side verification: LNPBP-9
  Paradigms descriptions can be found in 
GitHub here

RGB applies these general paradigms to Bitcoin transaction graph

• Single-use seals: transaction output-based seals (LNPBP-10; lnpbp::bp::txo_seals)
• Strict encoding: RGB consensus encoding (LNPBP-11; lnpbp::rgb::*)
• Cryptographic commitments:
  • deterministic bitcoin commitments (LNPBP-1, -2, -3; lnpbp::bp::dbc)
  • multi-contract commitments (LNPBP-4; lnpbp::lnpbps::lnpbp4)
• Client-side verification:
  • RGB schema (LNPBP-12; lnpbp::rgb::schema)
  • RGB contracts 
(LNPBP-13; lnpbp::rgb::{transition, stash, ancor, consignment})

Referencing issue #8

RGB is:

• a client-validated state and smart contract system working at 
Layer 2/3 on Bitcoin and Lightning Network;
• designed with confidentiality and scalability in mind.

Yes, RGB was designed to be ready for supporting Taproot, Schnorr, eltoo, multi-party LN channels, DLCs etc

• “Blueprints”/standards for constructing RGB contracts
.
  • The way ERC* defines token standards used for integration of Ethereum contract that issues some tokens into wallets and exchanges, Schema defines a standard for RGB assets.
• Schemas describe fungible assets, collectibles, digital identities etc.
• Issuer defines issuance contract, but in order to be supported by wallets/exchanges it must stick to (“validate against”) particular schema.
  • When wallets and exchanges get information (data and contract) about some asset, they need to validate it against a specific schema, that needed to be used for creating the asset. Only if the validation against that schema is passed, they can accept the request and start working with the asset.
• Wallets or exchanges will always use schema-based libraries (for example “RGB fungible assets”, “RGB collectibles”) instead of complex & universal core RGB library.

• Not limited by blockchain scalability: works on top of Lightning and any other channel.
• Amount of data kept by clients for full validation are significantly lower that in case of blockchain-based smart contract systems.
• Smart-contract-level sharding: multiple contracts keep independent history.

Ethereum uses ticker-based "Collections" for their NFTs architecture. From my understanding, minted ERC721 tokens must be minted to a collection. They're nice for organizational purposes e.g., artists can mint all NFTs to their personal collection making their entire portfolio easy to query. However, collections create friction because they are expensive to mint ($10-30 USD at current gas levels).

It seems a large part of Rarible's success can be attributed to allowing issuers to mint to their collection "RARI" (https://app.rarible.com/create/erc721) with minimal gas fees, whereas Opensea required issuers to mint a collection (They've just recently launched a product to bypass this: https://opensea.io/storefronts-staging).

In sum, collections are worthwhile as long as they can be minted with minimal fees. An optimization feature that's not available on Ethereum could be to allow Collections to be shared among multiple issuers. An example in which this can be useful is with art collectives and collaborations.

Transactions keep only homomorphic commitments which require no additional
storage.

2. State isolation: state is isolated between different smart contracts and they can interact only through special protocols (Spectrum) inside channels.

If you have two assets issued by different issuers, these assets don't interact directly, their data is never mixed and they cannot be cross-validated.

There is a way to exchange one asset for another one using Spectrum protocol, but it was created as a layer on top of Lightning Network and it is not related to RGB itself. Spectrum uses LN cooperation between different transaction graphs. When you make a multihop payment with Lightning, one transaction graph of one state channel is not directly affected by the data from the transaction graph of the other channel, they all communicate through the messaging P2P onion routing protocol. Spectrum works the same way for RGB in this regard.

Originally posted by @UkolovaOlga in #4 (comment)

It is reasonable to maintain a table for UTXO of all kinds, where one of the fields will be “right type” field + “state” field, specifying OwnedRightType and state data from the specific allocation. It’s important to note that txid:vout would not be a unique key, since a single UTXO may have multiple allocations. Maybe it can be done as two linked tables. And probably it will be good to keep that data in YAML file cache structured in that way as well.

What we need to distinguish is:

1. Bitcoin data structures, for instance UTXO
2. RGB data structures, for instance state transition, genesis, owned right assignment, state data, metadata
3. RGB concepts, which are not always directly mapped to (1) and (2), which are “single-use-seal”, “owned right”

Owned right

Owned right is a particular right (abstract concept); for instance in fungible assets these rights are:

• asset ownership
• inflation
• renomination
• burn epoch creation
• burn / burn-and-replace operation

An owned right may have some state data attached. Some rights do not have state data, and this called “declarative” (or “Void” previously).
Also, an owned right is always attached (we call that “assigned”) to a specific UTXO.

Assignment

Assignment is an owned right (defined by owned right type u8 value) + state data + UTXO, which forms a single-use-seal definition when it is assigned that owned right.

So: nothing can prevent some given UTXO from having multiple assignments, of different owned right type, and even for each owned right type there might be multiple assignments.

UTXO <-one to many-> owned right type <-one to many-> assignment of some state:

• assign an inflation right to it (one)
• assign ownership right fo 100 of USDT
• assign ownership right of 10 Apple shares under different contract
• assign ownership right of 10000 of USDT again

This is a very bad situation, but we can’t prevent it from happening.
Especially if you assign different types of owned rights under the same contract you may not be able to create a state transition without loosing some of the rights or assets (since state transitions have a very strict set of owned rights type for which they can close seals). That is why @dr-orlovsky has created “split rights" state transition, which does only one thing - gives the ability to split those mixed rights into different UTXOs.

The open question is still how this multiplicity of UTXOs has to be managed.

Originally, the name RGB was chosen because the project started as a "better version of colored coins". Then, already during the few weeks into the research work with Peter Todd, in 2018, it diverged so much that it has nothing to do anymore with colored coins. But the name stuck.

Owned right is a particular right (abstract concept); for instance in fungible assets these rights are:

• asset ownership
• inflation
• renomination
• burn epoch creation
• burn / burn-and-replace operation

An owned right may have some state data attached. Some rights do not have state data, and this called “declarative” (or “Void” previously).
Also, an owned right is always attached (we call that “assigned”) to a specific UTXO.

Bifrost is a planned server that will act as a public key-value storage for keeping (encrypted) information on client-validated data. In simple words, you can think about it as a generalization of Watchtower concept, which will do the following:

• Store information about known issued assets (genesis etc)
• Store public/disclosed parts of RGB history from issuers (like the ones related to prunning)
• Can be used by RGB users to receive payments when they are offline (i.e. it will store the data for them, in encrypted form)
  It will have its own API (RPC), which will be done with LNP.

It is not the same as RGB node b/c it is a public service (while RGB is a private thing keeping your stash unencrypted).

So, Bifrost to RGB is something like Watchtowers are to LN node (but more functional).

Even taking into account the fact that RGB is based on bitcoin transaction graph (which, in turn, is based on bitcoin timechain),
RGB itself is not a 'blockchain'. It’s a form of a DAG, where you don’t have the data on a complete state of the network, ever.
From the moment you create a smart contract and transfer the state to some other party, you have neither the control over that state
(only the new state owner has it), nor the information on how that state actually evolved.

For example, as an asset issuer you will never know, who are the owners of your issued assets. When you assign the state of the asset
to some bitcoin transaction output, you don’t know which output it is, because the party that receives that data, provides you
with the information about transaction output, blinded with random data. Taking into account that you don’t know that random data
used for blinding, you can’t say which output you are paying to or transferring some rights to.

This is very different from the blockchain-based smart-contract paradigm, where you store the complete history of the blockchain.
This is why we say that RGB is a partial-state smart-contract system (the first of its kind). It is still globally consistent,
not contradicting the fact of this state partiality, due to the usage of single-use seals that enable reaching consensus on state validation.
As a user, whenever I receive some state into my ownership and even without knowing the whole state of the system, I am still able to validate:
that this state of the system was not faked, that it has been uniquely committed, that there were no double spending events (even up to genesis
of the asset issuer).

Social consensus on the client-side validation rules also makes it possible to be sure that every further owner of the asset will apply the same validation rules as I do. How? Every asset/state
validation rules are defined by Schema at genesis level, meaning that every further owner of the asset still uses the same Schema to validate the history against. Thus, here Schema is actually the means to guarantee the social consensus on the validation.