RGB FAQ
  • Welcome to RGB!
  • 💡What is RGB?
  • 📚RGB Resources
  • ⚙️RGB design principles
  • 🎓RGB paradigms
    • Single-use seals
    • Cryptographic commitments
    • Client-side validation
    • Strict encoding
  • 🔖RGB Smart contracts
    • What is a smart contract?
    • What is contract schema?
    • How does one program RGB smart contracts?
    • Do you define the validity of a state transition with Schema?
  • ☣️RGB & ₿itcoin
    • Will RGB require a fork of Bitcoin or Lightning?
    • RGB testnet & mainnet
    • Taproot, Schnorr signatures and RGB
    • Does anything need to happen in Lightning or Bitcoin to enable Lightning on RGB?
    • Is there a plan to work on channel factories?
  • 🎨RGB NFT
    • RGB NFT vs other NFT
    • What's the difference between RGB design of NFTs and common NFT approach?
  • ❓FAQ
    • What is RGB?
    • What does 'RGB' stand for?
    • Is RGB a new blockchain?
    • What can I do with RGB?
    • Is it possible to create a DAO with RGB?
    • RGB vs alternatives
    • Is RGB Turing-complete?
    • Does RGB require Taproot?
    • What RGB is compatible with?
    • Will Simplicity be used in RGB?
    • Why there is no RGB MVP with updates rolling out after?
    • How is confidentiality reached in RGB?
    • How is safety reached in RGB?
    • What is client-side validation?
    • How scalable is RGB?
    • Is there an RGB "Hello World" guide?
  • 📖Glossary
    • Contracts
      • ContractId
      • NodeId
      • Node
      • State
      • State assignment
      • State transition
      • Assignment
      • Assignment variant
      • State data
      • State type
      • Metadata fields
      • Metadata
      • Data type
      • Genesis
    • AluVM
    • Bifrost
    • Client-side validation
    • Contractum
    • Deterministic Bitcoin commitments
      • Container construction/deconstruction
      • Container
      • Commitment
      • Commitment embedding
      • LockScript
      • Proof
      • Protocol-specific entropy
      • Supplement
    • Right
    • Schema & Scripts
      • Schema
      • Field type
      • Assignment type
      • Bit dimensions
      • ABI
      • Script library
      • Occurence boundaries
      • Script extensibility
      • Transition type
    • Single-use seals
      • Witness
      • Seal definition
      • Seal blinding
      • Multimessage commitments
      • Seal closing over message
    • Stash
      • Stash
      • Consignment
      • Disclosure
      • Anchor
      • Forget procedure
      • Merge procedure
      • Validate procedure
      • Conceal procedure
      • Consign procedure
    • Encodings
      • Merklization commitment encoding
      • Storage encoding
      • Strict encoding
      • Pedersen commitments
      • Blinding factors
      • Buletproofs
      • Conceal
      • Commitment encoding
  • 🙋Community
    • Developer calls
    • Presentation slides
    • YouTube
    • Getting familiar with RGB
    • Articles & interviews on RGB
Powered by GitBook
On this page

Was this helpful?

  1. Glossary

Bifrost

Bifrost is an extension to the LN peer-to-peer protocol, which would allow you to send client-side validation data using the LN itself, make RGB-20 payments over the LN and enable more advanced things in the future: DEX, decentralized storage, DeFi, advanced smart contracts etc.

To emphasise once again, Bifrost is not a part of RGB, it's an additional protocol that makes it possible for mobile RGB wallets to work on LN. One of the features of this protocol can be imagined as an improved version of Watchtowers currently present in LN and not breaking the backwards compatibility.

From the programming standpoint, unlike RGB or client-side validation technologies, Bifrost is much more flexible, meaning that we can start with rolling out a simple version of it (a few methods are already written in code, so we just need to extend it a bit more to cover the use case of sending over the client-side validated data) and then update it with new functionality further down the road, potentially maybe even becoming a part of LN itself.

From user perspective Bifrost is needed to be finalized before the RGB release both as a protocol and as a code that can be put into mobile wallets thus also showcasing how RGB over LN transfers can be used from a mobile device.

From a more technical point of view, Bifrost also acts as a public key-value storage for keeping information on client-validated data in encrypted way. You can think about it as a generalization of Watchtower concept, which will allow any node to implement the following functionality:

  • Store & propagate information about RGB schema and assets (enabling RGB P2P infrastructure)

  • Store public/disclosed parts of RGB history from issuers (like the ones related to pruning)

  • Store encrypted information about RGB payments (consignments) - for a fee (“RGB watchtower”)

  • Run DEX on LN with RGB

  • 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

The original idea was to do it as a standalone node with the same name, however since all of this functionality will be part of lightning P2P protocols, it will require LN node next to it anyway, so for now we are planning to just add “Bifrost protocol support” to the existing LNP Node as a compilation flag/extension/plugin - so other nodes will be also able to add this features later. It is not the same as RGB node, because 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). As for the normal lightning watchtowers, the BOLT-12 protocol draft is there, so it will not be a part of Bitfrost protocol spec - but will also be implemented in the LNP Node.

PreviousAluVMNextClient-side validation

Last updated 3 years ago

Was this helpful?

📖