RGB protocol announcement

- ### Global state in RGB contracts
  Now each RGB contract has a global state accessible by a virtual machine
  and clients (wallets etc).
- ### Contract interfaces
  Interfaces, introduced in this version, represent a standard way of
  communicating a diverse range of smart contracts through well-defined APIs.
  Interfaces can be compared to contract ABIs and ERCs in Ethereum world,
  however, unlike in Ethereum, they require neither obligatory standardization
  (as ERCs) nor separate distribution, being always packed together with
  contracts. By using interfaces, wallets and other software can provide a
  semantic-aware UI for the users for working with the contracts - and contract
  developers may add more interfaces to their existing contracts over time
  without the need to update the immutable contract itself.
- ### Strict type system
  Strict types is a new functional data type system with provable
  properties used for the RGB contract state representation and introspection.
  It allows compile-time guarantees on the size of any data, simplifying RGB
  operations on low-end and limited-memory devices like hardware wallets.
  The whole RGB consensus layer is now compiled into strict types, which
  allows formal proofs of the binary compatibility between releases (the
  feature which might have been very useful for bitcoin consensus if it existed
  back in the days of Satoshi). You can learn more about strict types on
  <https://www.strict-types.org>
- ### Contracts in Rust
  Writing and compiling an RGB smart contracts in Rust. Thanks to the strict
  types, it is also possible to compile rust data types right into RGB
  contracts.
- ### State introspection
  Contracts can introspect their own state in the validation code used by the
  virtual machine, which unlocks the way for writing complex forms of contracts
  working with bitcoin transactions, DLCs and other complex data.
- ### URL-based invoice format
  Previously RGB was using Bech32m-encoded invoices, which were very long,
  not human-readable and couldn't be automatically opened with most of the
  software. The new format is much shorter, easier to verify by the user and
  can be opened automatically as a link with a preconfigured software.
- ### WASM support
  RGB standard library can run without I/O and file system access,
  i.e. can operate inside a web page or a browser plugin.
- ### Tapret descriptors and custom derivation
  RGB uses taproot-based OP_RETURN commitments (in short - tapret), which
  require support on the descriptor level such that wallets could see the
  transactions with tweaked outputs as those belonging to the wallet descriptor.
  New version also introduces custom derivation indexes that prevent non-RGB
  wallets from accidentally spending outputs with RGB assets (and thus -
  destroying assets).
- ### Simplified dependencies
  RGB consensus layer is being shipped with fewer dependencies, improving the
  stability of API. We have abandoned the dependency on custom bulletproofs
  implementation from Grin projects. We also do not use rust-bitcoin and
  rust-miniscript due to their overall API instability and recently discovered
  bugs; since RGB uses a very small subset of bitcoin functionality it is now
  implemented as a part of the library with no assumptions about bitcoin
  consensus layer (like those which halted rust-bitcoin powered software when
  Burak's hack had happened last year).
- ### Simplified integration
  Many operations that previously required multiple API calls, as well as
  cross-language encoding of complex data structures now work with a
  single API call. RGB contract state is represented as a JSON object and
  can be serialized across different languages without a hassle.
- ### Simplified UX
  Previously, to use RGB, a wallet or a user had to run the RGB Node, interface
  it through RPC (or cli tool) - and use a number of other libs and command-line
  tools to perform most of the operations on PSBTs etc. With the new release
  this complex stack was replaced by a single library API and a command-line
  tool `rgb`, which operate like a swiss knife for RGB user (and it can be
  compared to the way `git` works). RGB Node still can be run by users on their
  home servers, but is not obligatory for using RGB anymore.
- full support of bitcoin layer 1 and channel state introspection;
- inter-contract interaction;
- bulletproofs++ support;
- zero-knowledge-based optimizations of the client-side-validated history.
- MyCitadel wallet (iOS, Desktop)
- Iris wallet (Android) from RGB team inside Bitfinex
- BitMask (Web browser plugin) from DIBA
- LNP Node with RGB support - lightning node from the LNP/BP Standards Association
- RGBEx.io - website listing RGB assets and contracts,
  using pseudonymous credentials (public key + signatures)
- RGB Tools library - SDK based on BitcoinDevKit for RGB wallet integration
- LightningDevKit with RGB support - again by RGB team in Bitfinex
- Core Lightning RGB plugin
- Completing RGB documentation, specification and helping public audits of the
  technology. Right now we have a nearly-complete RGB whitepaper [6] a codified
  standards [7]
- Lightning network support for complex RGB smart contracts - the thing we name
  #BiFi (Bitcoin finance) [8]. It includes further development of Storm -
  a decentralized data storage & messaging network on top of Lightning, that we
  presented last year.
- RGB toolchain, which includes a new high-level functional smart contracting
  language called Contractum (<https://www.contractum.org>) and other tools
  which will simplify the life of RGB devs.
All releases and major things are being announced on:
* Official website of the protocol <https://rgb.tech>,
  community <https://rgbfaq.com> and LNP/BP Standards Association
  <https://lnp-bp.org>.
* Twitter of the Association: <https://twitter.com/lnp_bp>
* Community telegram channel: <https://t.me/rgbtelegram>
> RGB v0.10 can be downloaded and installed as described on
> <https://rgb.tech>
> website, which also contains a number of user and developer guidelines.
> RGB source code can be found on <https://github.com/RGB-WG>
> My goal with RGB was not just to enable assets on Lightning, but that
> of a much larger scope: to build a programmability layer for Bitcoin
> and Lightning, which may unlock other cases than just tokens - DAOs,
> decentralized identities and other things that bitcoin itself was
> lacking.
- Bob doesn't believe that there's a number which can be multiplied by 2
   to produce 4.  He's willing to pay a bounty for proof that he's wrong
   but Bitcoin does not currently provide a multiplication opcode, so he
   can't simply pay a script that says: "2 OP_MUL 4 OP_EQUAL"
- Bob hears that RGB has turing-complete scripting, so he buys some
   random tokens that have an RGB contract which allows him to encumber
   them by any AlumVM script.  He then creates a Bitcoin transaction
   signed SIGHASH_NONE|SH_ANYONECANPAY that will allow anyone knowing the
   solution to (x * 2 == 4) to spend his RGB-based tokens.  He publishes
   a PSBT for the transaction along with the RGB data needed to claim the
   tokens.
- Anyone on the network can now claim the BTC without knowing the
   solution, destroying the RGB-based tokens.
- If, instead, Bob hears that Mallory knows the solution, he could sign
a
   PSBT with the default SH_ALL to her, but then Mallory could take the
   BTC without solving the problem, again destroying the RGB-based
   tokens.
- Or, in another case, Bob hears that Alice knows the solution, but he
   doesn't want to risk his tokens being destroyed, so he refuses to sign
   a transaction paying Alice until she provides him the answer.  When
   Alice does provide him the answer, and he realizes it's so simple, he
   changes his mind about paying her and doesn't sign his transaction to
   her.  She has no recourse.
> We're also working on the design of a layer 1 which will be perfect for
> the
> client-side-validated applications (“how to design a blockchain today
> if we
> knew about client-side-validation/single-use-seals”). This should be
> very
> compact (order of one signature per block) ultra-scalable
> (theoretically
> unlimited no of tx in a block) chain which can run systems like RGB -
> with
> Bitcoin UTXO set migrated into RGB [...]
* * *
> Nevertheless, in 2021 we were able to present both RGB powered with a
> Turing-complete virtual machine (AluVM) [2] and RGB had became
> operational on
> Lightning Network [3] using the LNP Node - a complete rust
> re-implementation of
> the Lightning protocol made by me at the Association [4].
> Despite 4 years of active development, weekly community calls, talks on
> all mainstream bitcoin-only evens and conferences, the awareness about
> RGB
> in the bitcoin community is still very small
> Hi Dr Orlovsky,
>
> Thank you for writing about your interesting project.  Some replies
> inline below:
>
> On 2023-04-10 12:09, Dr Maxim Orlovsky via bitcoin-dev wrote:
> > RGB v0.10 can be downloaded and installed as described on
> > <https://rgb.tech>
> > website, which also contains a number of user and developer guidelines.
> > RGB source code can be found on <https://github.com/RGB-WG>
>
> FYI: the RGB-WG organization page links to a repository whose latest
> release is 0.9 and whose latest commit is titled, "Release v.0.9.1", see
> https://github.com/RGB-WG/rgb-node/
>
> > My goal with RGB was not just to enable assets on Lightning, but that
> > of a much larger scope: to build a programmability layer for Bitcoin
> > and Lightning, which may unlock other cases than just tokens - DAOs,
> > decentralized identities and other things that bitcoin itself was
> > lacking.
>
> Is there any documentation or discussion archives that address the
> problem of non-publishable conditional statements seemingly being
> insecure in
> multiparty protocols, as previously described on this list[1] by Ruben
> Somsen?  To give my own example of the problem:
>
> - Bob doesn't believe that there's a number which can be multiplied by 2
>    to produce 4.  He's willing to pay a bounty for proof that he's wrong
>    but Bitcoin does not currently provide a multiplication opcode, so he
>    can't simply pay a script that says: "2 OP_MUL 4 OP_EQUAL"
>
> - Bob hears that RGB has turing-complete scripting, so he buys some
>    random tokens that have an RGB contract which allows him to encumber
>    them by any AlumVM script.  He then creates a Bitcoin transaction
>    signed SIGHASH_NONE|SH_ANYONECANPAY that will allow anyone knowing the
>    solution to (x * 2 == 4) to spend his RGB-based tokens.  He publishes
>    a PSBT for the transaction along with the RGB data needed to claim the
>    tokens.
>
> - Anyone on the network can now claim the BTC without knowing the
>    solution, destroying the RGB-based tokens.
>
> - If, instead, Bob hears that Mallory knows the solution, he could sign
> a
>    PSBT with the default SH_ALL to her, but then Mallory could take the
>    BTC without solving the problem, again destroying the RGB-based
>    tokens.
>
> - Or, in another case, Bob hears that Alice knows the solution, but he
>    doesn't want to risk his tokens being destroyed, so he refuses to sign
>    a transaction paying Alice until she provides him the answer.  When
>    Alice does provide him the answer, and he realizes it's so simple, he
>    changes his mind about paying her and doesn't sign his transaction to
>    her.  She has no recourse.
>
> It seems to me, based on my understanding of Somsen's original insight,
> that client-side validation by itself cannot enforce conditions in a
> trustless multiparty setting.
>
> I think that implies that it's only possible to enforce conditions in a
> consensus system (or in a trust-dependent system), which would have
> significant implications for the future direction of your work, as you
> wrote in your email:
>
> > We're also working on the design of a layer 1 which will be perfect for
> > the
> > client-side-validated applications (“how to design a blockchain today
> > if we
> > knew about client-side-validation/single-use-seals”). This should be
> > very
> > compact (order of one signature per block) ultra-scalable
> > (theoretically
> > unlimited no of tx in a block) chain which can run systems like RGB -
> > with
> > Bitcoin UTXO set migrated into RGB [...]
>
> * * *
>
> Looking at other parts of your email:
>
> > Nevertheless, in 2021 we were able to present both RGB powered with a
> > Turing-complete virtual machine (AluVM) [2] and RGB had became
> > operational on
> > Lightning Network [3] using the LNP Node - a complete rust
> > re-implementation of
> > the Lightning protocol made by me at the Association [4].
>
> Could you clarify the status of these implementations?  While trying to
> learn about RGB, I noticed that you don't have much completed
> documentation.  Previous reviewers also mentioned this and I saw that
> you suggested them to read the code or view your videos.
>
> When reading your code for your LN implementation (LNP), I noticed it
> seemed to be missing a lot of things present in other LN implementations
> I regularly review.  For example, I can't find where it supports
> creating or parsing onions, which seems to be a fundamental requirement
> for using LN.  In trying to figure out how it works, I also noticed that
> I couldn't find either unit tests or integration tests---indeed several
> of your applications seem to almost entirely lack the string "test".
> For example, here are LNP-node and RGB-node compared to the four LN
> implementations I regularly monitor:
>
> /tmp/rgb-node$ git grep -i '\<test\>' | wc -l
> 7
> /tmp/lnp-node$ git grep -i '\<test\>' | wc -l
> 4
>
> ~/repos/rust-lightning$ git grep -i '\<test\>' | wc -l
> 2008
> ~/repos/cln$ git grep -i '\<test\>' | wc -l
> 1459
> ~/repos/lnd$ git grep -i '\<test\>' | wc -l
> 3547
> ~/repos/eclair$ git grep -i '\<test\>' | wc -l
> 2576
>
> I realize those are all projects by larger teams than that which works
> on RGB, but a difference of three orders of magnitude is very surprising
> to me.  Do you have out-of-tree testing or am I missing something else?
> I did my best to earnestly search both your repository and your GitHub
> issues and PRs.  All I found was that a small amount of previous unit
> testing was removed, and that several issues mentioning the need for
> testing were closed without referencing a resolution.
>
> As your replies to previous reviewers also mentioned that they should
> view your Youtube videos, I also tried that.  I focused on the ones
> discussing LNP, as LN is something I know fairly well, and I admit that
> I skimmed them quite fast, but I couldn't find any demos where you
> progressed beyond using LNP to open a channel with another node.  E.g.,
> they seemed to stop at the same point as this demo:
>
> https://github.com/LNP-WG/lnp-node/blob/c402decc9ff5b557a9e3d542f74e2fd6ed856742/doc/demo-alpha.4/README.md
>
> > Despite 4 years of active development, weekly community calls, talks on
> > all mainstream bitcoin-only evens and conferences, the awareness about
> > RGB
> > in the bitcoin community is still very small
>
> My understanding of the basic goal of RGB from years ago was that it
> would allow ordinary users to define new assets on Bitcoin in a way that
> would allow those assets to be transferred over LN.  As far as I can
> tell, it doesn't do that yet, not even in a way that's accessible to a
> power user such as myself.  Even for that original goal, there are
> several problems outstanding---problems which will likely require
> significant research and experimentation to overcome, e.g.[2].
>
> Instead of tackling those problems and building upon existing wallet and
> LN libraries, I see an ambitious effort at reimplementation and massive
> scope creep.  The payoff for that effort could be a huge change that
> affects how we use Bitcoin and LN for decades to come.  But it also
> seems possible that the ambition and scope creep may be preventing the
> project from currently serving many of the people who were most excited
> about it in the first place.  Awareness may be limited because the
> near-term benefits for most people who invest time in learning about RGB
> also seems limited.
>
> Thanks again for writing about your research for this mailing list,
>
> -Dave
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003540.html
> [2]
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003549.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> FYI: the RGB-WG organization page links to a repository whose latest
> release is 0.9 and whose latest commit is titled, "Release v.0.9.1", see
> https://github.com/RGB-WG/rgb-node/
> > Nevertheless, in 2021 we were able to present both RGB powered with a
> > Turing-complete virtual machine (AluVM) [2] and RGB had became
> > operational on
> > Lightning Network [3] using the LNP Node - a complete rust
> > re-implementation of
> > the Lightning protocol made by me at the Association [4].
>
> Could you clarify the status of these implementations?
> While trying to
> learn about RGB, I noticed that you don't have much completed
> documentation. Previous reviewers also mentioned this and I saw that
> you suggested them to read the code or view your videos.
> When reading your code for your LN implementation (LNP), I noticed it
> seemed to be missing a lot of things present in other LN implementations
> I regularly review. For example, I can't find where it supports
> creating or parsing onions, which seems to be a fundamental requirement
> for using LN.
> In trying to figure out how it works, I also noticed that
> I couldn't find either unit tests or integration tests---indeed several
> of your applications seem to almost entirely lack the string "test".
> For example, here are LNP-node and RGB-node compared to the four LN
> implementations I regularly monitor:
>
> /tmp/rgb-node$ git grep -i '\<test\>' | wc -l
> 7
The real RGB code is here, as it is clearly stated in the Github:
* consensus-level
  - <github.com/RGB-WG/rgb-core>
  - <github.com/BP-WG/bp-core>
  - <github.com/LNP-BP/client_side_validation>
* integration libraries - <github.com/RGB-WG/rgb-wallet>
With the update to v0.10 a lot of code was changed, so most of tests
got outdated and were thrown out. Yes, we need more time and
effort to re-do them -- but even taking that into the account,
the core of RGB is covered to much greater extent than the estimations
you have provided:
* client-side-validation library - 80%:
  <https://app.codecov.io/gh/LNP-BP/client_side_validation>
* RGB Core - ~25% (due to significant re-write in v0.10)
  <https://app.codecov.io/gh/RGB-WG/rgb-core>
> /tmp/lnp-node$ git grep -i '\<test\>' | wc -l
> 4
>
> ~/repos/rust-lightning$ git grep -i '\<test\>' | wc -l
> 2008
> ~/repos/cln$ git grep -i '\<test\>' | wc -l
> 1459
> ~/repos/lnd$ git grep -i '\<test\>' | wc -l
> 3547
> ~/repos/eclair$ git grep -i '\<test\>' | wc -l
> 2576
> I realize those are all projects by larger teams than that which works
> on RGB, but a difference of three orders of magnitude is very surprising
> to me. Do you have out-of-tree testing or am I missing something else?
> As your replies to previous reviewers also mentioned that they should
> view your Youtube videos, I also tried that.
> I focused on the ones
> discussing LNP, as LN is something I know fairly well,
> I skimmed them quite fast, but I couldn't find any demos where you
> progressed beyond using LNP to open a channel with another node. E.g.,
> they seemed to stop at the same point as this demo:
> https://github.com/LNP-WG/lnp-node/blob/c402decc9ff5b557a9e3d542f74e2fd6ed856742/doc/demo-alpha.4/README.md
> My understanding of the basic goal of RGB from years ago was that it
> would allow ordinary users to define new assets on Bitcoin in a way that
> would allow those assets to be transferred over LN. As far as I can
> tell, it doesn't do that yet, not even in a way that's accessible to a
> power user such as myself.
> Even for that original goal, there are
> several problems outstanding---problems which will likely require
> significant research and experimentation to overcome, e.g.[2].
> Instead of tackling those problems and building upon existing wallet and
> LN libraries, I see an ambitious effort at reimplementation and massive
> scope creep.
The real part of the story is that 80% of the time we were working
on solving the original scope you pointed out. It just appeared that
there were much more hidden stones (than was expected back in 2018)
in doing the idea of "assets over Lightning":
* the original single-use-seals didn't worked for the world of multiple
  assets which may co-exists, which required development of a set of
  quite complex protocols (still being probably most complex part
  of RGB);
* the original pay-to-contract commitment scheme did work badly on
  practice, being poorly inter-operable with existing lightning
  implementations (which took a year of work on LNP node in total,
  as I mentioned above) and leading to hard problems in wallet
  integration and compatibility with all existing frameworks. We were
  solving that problem until Taproot had arrived - and then we switched
  to Taproot-based commitment scheme. It took another half of year
  to update the whole code base - but the reward was compatibility
  with BDK, LDK and other existing tools in the ecosystem, so your
  comment on "Instead of tackling those problems and building upon
  existing wallet and LN libraries" is not valid;
* as a part of the above, I had to significantly contribute to
  taproot implementation and maintenance of rust-bitcoin project,
  being the most active project contributor during the course of
  2019-2022 [3] (="building upon existing wallet libraries);
* a lot of time was spent on privacy-related improvements, since none
  of the original authors nor sponsors had seen any value about putting
  "colored coins on lightning" without worriyng about the privacy;
and only after that comes some "fancy stuff", like doing a dedicated
virtual machine and rich data type system -- which primary features
were not "Turing completeness" but ability of formal verification and
compiler-time safety guarantees. For instance, the developed type
system [4] allows not just to "compile" any rust data type into a
smart contract, but also to prove that all data types used in
consensus code do not mutate between releases. If bitcoin had that
type system, there would be no "unnoticed" hardforks or risks of them
in a future -- and I think not implementing such system in doing a
new consensus protocol would be a poor decision. And the last, but
not least, I do not want to be in such situation
<https://twitter.com/fiatjaf/status/1647976362374844416?s=61&t=H4U6Q30N4eanvS4GjyAt4g>
preferring to spend a year more on a proper design instead of
"shipping earlier". What is acceptable for networking protocols
can't be acceptable for consensus-level protocols, which, unlike
even blockchain consensus can't have softforks.
> To give my own example of the problem <… description follows …>
1. Assume we have some BTC lifted to RGB, which we will name BTC*.
   (let’s leave the question on how to do that aside; it can be
   discussed separately).
2. > Bob doesn't believe that there's a number which can be
   multiplied by to produce 4. He's willing to pay a bounty for
   proof that he's wrong.
   This part I will take from your letter without changes, however
   will skip the rest about production of some tokens etc, which
   is unnecessary here.
1. The value of BTC* is preserved within the contract not attached
   to any of UTXOs (it has become possible with RGB v0.10
   introduction of “global state”)
2. BTC* can be reclaimed by any party providing a solution (in form
   of RGB **state extension**) which is verified by AluVM. Alice,
   if she have found the solution, now can **assign** that
   previously “floating”/unowned BTC* to an UTXO she controls.
   State extensions were introduced into RGB in late 2020 v0.4.
   State extensions are different from a normal state transitions
   by the fact that they do not have inputs referencing some
   previously-owned (i.e. assigned to an UTXO) state, i.e. their
   creation doesn’t require creation of a corresponding bitcoin
   transaction spending some UTXOs with a state (as it is in case
   of a state transitions).
3. To ensure uniqueness of the winner (i.e. prevent
   “double-spending” of “free-floating”/unowned BTC* from the
   contract global state) Alice is also required (by the contract
   conditions defined by Bob in the contract schema) to post some
   identifiable information into a mined bitcoin transaction
   on-chain (NB: this is not the same as a witness transaction; it
   can be any transaction not related to the contract UTXOs in any
   way). The transaction must contain a pre-defined signal in a
   form known only to the contract participants; for instance some
   pre-defined random value stored in OP_RETURN, address, value,
   witness, pay-to-contract tweak of some pre-defined pubkey - or
   anywhere else. This can re-use a transaction which can be mined
   anyway (like a payment that happens in parallel) and can even
   avoid additional block space consumption if something like P2C
   or tapret commitment is used (though this will require
   a pre-knowledge of public keys at the moment of contract
   creation). The contract script claims that only the first
   party who had made such tx mined wins the game (if two txes are
   mined in a block, they may be sorted by their txid or block
   position). Because of AluVM, contracts can inspect on-chain
   bitcoin state and find the signal.
1) for Lightning channels, which has the same level of
   trustlessness as the pure BTC in LN;
2) on-chain "lifting" which is semi-trusted (trustless private
   decentralized peg-in and semi-trusted federated peg-out
   requiring user+federation multisig but no privacy/history
   exposure thanks to zk; such on-chain lifting is still much
   better than other alternatives with drivechains or federated
   sidechains).
> Is there any documentation or discussion archives that address the
> problem of non-publishable conditional statements seemingly being
> insecure in multiparty protocols, as previously described on this
> list [1] by Ruben Somsen?
> 1. Assume we have some BTC lifted to RGB, which we will name BTC*.
>    (let’s leave the question on how to do that aside; it can be
>    discussed separately).
- Xavier and Yasmin create an RGB contract that says any BTC deposited
   into multi(2,x,y) can be used as BTC\*
- Bob acquires some of this BTC\*
- Bob offers his BTC\* to anyone who can provide x for (4 == 2 * x)
- Alice knows x = 2
- Alice asks Xavier and Yasmin to sign an onchain transaction
   withdrawing Bob's BTC\*. She provides them proof that Bob offered his
   BTC\* and that she knew the answer.  The both sign the the
transaction.
> Ok, I think I understand you, but I'd like to try rephrasing what you
> wrote in a very brief format to see if you agree that it's correct and
> in the hopes that it might help other Bitcoin/LN developers understand.
> What it doesn't provide is trustless contracting beyond the
> capabilities of Bitcoin script.
1. We may have a trustless BTC* in lightning channels (including
   multiparty channels with many participants).
2. It also depends on how you define the value of the original BTC.
   If BTC is a coin existing in bitcoin blockchain, than yes - you
   can't have a fully trustless BTC* for on-chain operations. But if
   you define BTC as a digital scarcity strictly inheriting existing
   UTXO  set from bitcoin blockchain, but which may exist elsewhere
   than bitcoin blockchain, you may have a 100% trustless BTC*.
> In short, I think this capability of RGB allows easily creating
> user-defined sidechains based on arbitrary scripts.
1. Bearer securities - corporate shares, bonds, options, futures etc.
   They will be 100% confidential and censorship-resistant + scalable
   b/c of Lightning network. Yes, you still trust the issuer (like with
   corporate shares), but the the secondary market is much improved.
2. Bearer ownership rights ("NFTs done in the right way"), again
   private, scalable, not polluting blockchain. For instance, I would
   like to have all books & songs as a bought to be present in this
   format. This also opens options for creators to earn commissions not
   just from an initial sale, but also from secondary market.
3. Digital collateral-based stable coins (in terms of their purchasing
   power and not necessary linked to any fiat).
4. Digital identity, where RGB and single-use-seals make key revocation
   a global event. Without this it is impossible to prove that a given
   key was or was not revoked at certain date.
5. Decentralized naming systems - like ENS, but much better because
   no ethereum is required :)
6. Provable historical event logs: opentimestamps doesn't allow
   proving that there is no alternative commitments. With RGB it is
   possible to build event logs which has 100% trustless provable
   properties that no alternative history of the events does exist.
   For instance, if a doctor gives a prediction that a baby will be
   a boy and not a girl, it is impossible to witness the case with
   OpenTimeStamp (the doctor can make 2 OTSes for both outcomes),
   while with RGB it can be proven that no alternative commitment was
   created.
7. Liquidity pools, DEXes, AMM and other fancy stuff on Lightning,
   which we call "BiFi" (Bitcoin finance). One may listen to the talk
   on the last Bitcoin Amsterdam conference where I have presented
   that concept [1]. It requires more than just RGB - also some
   improvements to the Lightning network and protocols like Storm
   as a decentralized (tokenless!) data layer - but all of that is
   WIP at LNP/BP Standards Association with many parts already being
   released in a test versions (another reason why LNP Node is
   important - a topic we were discussing two e-mails ago).