RGB and

Lightning Network

Alekos Filini (@afilini) - Developer at BHB Network

Giacomo Zucco (@giacomozucco) - Founder of BHB Network

RGB Recap

  • Generic assets on Bitcoin
  • "Client Side Validation" model
    • = when you receive a tx you validate that specific chain of proofs
  • Concept of "seals" which can be closed only once
    • One UTXO = one "seal" (since it can only be spent once)
  • We "bind" tokens to an open seal
  • When we close it we specify the new seal which will "own" the tokens

RGB Recap

  • Contracts are the "coinbase" of every asset
    • Kept off-chain (and published online), with a small commitment on the blockchain
    • Different type of contracts have different "behaviors"
    • You have to trust them
  • Proofs are used to prove and transfer the ownership of tokens
    • Kept off-chain, with zero-overhead commitment on the blockchain
    • Different type of proofs have different "behaviors"
    • You don't have to trust them

RGB Recap

  • Two different commitment schemes
    • Good old OP_RETURN
    • Pay-to-contract
      • Tweak a pubkey using the proof we want to commit to
  • Contracts are always deployed using OP_RETURNs
  • The contract decide how the proofs will have to be committed on the blockchain

RGB & LN

  • UTXO-based: can leverage any "smart contract":
    • payment channels
    • HLTC routing (& Bitcoin liquidity!!!)
  • LN improves privacy & scalability, min concerns for CC schemes

RGB & LN

  • Client Side Validation Pros:
    • Better privacy
    • No conflict over scarce resources
    • No "SPV" problem
  • Client Side Validation Cons:
    • You need to negotiate a direct connection
    • You need to be online to receive
    • You need to backup stuff other than the seed
  • Lightning Network Cons:
    • You need to negotiate a direct connection
    • You need to be online to receive
    • You need to backup stuff other than the seed

And now...

...the boring stuff...

RGB Outputs

  • In proofs we can move tokens in two ways
    • By specifying a precise UTXO (txid, index pair)
    • By specifying on output of the BTC TX that spends the previous UTXO

Moving on top of LN

  • New message types for incompatible messages
    • Even values => drop connections with "vanilla" nodes
  • Define a BOLT #3 for proofs
    • Ensure that different implementations build the proof in the same way
  • Make sure "vanilla" nodes pass our messages around
  • Choose some feature bits (mostly odd bits)

Fee and Exchange Rate Signaling

  • Instead of advertising a fee-rate for HTLC relay we also add two exchange rates (asset/SAT - SAT/asset)
    • We can build mixed paths moving "in and out" of RGB
  • This is kind of tricky: we have to rely on "vanilla" nodes to spread P2P messages around - even if they don't understand them

Channel Opening

+-------+                                      +-------+
|       |--(1)-----  rgb_open_channel  ------->|       |
|       |<-(2)------  accept_channel  ---------|       |
|       |                                      |       |
|       |--(3)--  funding_created + proof  --->|       |
|   A   |<-(4)------  funding_signed  ---------|   B   |
|       |                                      |       |
|       |--(5)------- funding_locked  -------->|       |
|       |                                      |       |
|       |  (6)   B (checks the on-chain tx)    |       |
|       |<-(7)------- funding_locked  ---------|       |
+-------+                                      +-------+

- where node A is 'funder' and node B is 'fundee'        
  • At step 6, B checks that the on-chain tx really commits to the proof shown before 

Payment Routing

+-------+                            +-------+
|       |--(1)---- add_htlc -------->|       |
|       |--(2)-- rgb_add_htlc ------>|       |
|       |<-(3)-- rgb_add_htlc -------|       |
|       |                            |       |
|       |--(4)----   commit   ------>|       |
|   A   |                            |   B   |
|       |<-(5)--- revoke_and_ack-----|       |
|       |<-(6)----   commit   -------|       |
|       |                            |       |
|       |--(7)--- revoke_and_ack---->|       |
+-------+                            +-------+
        
  • Routing fees are always paid in Bitcoin
  • Additional metadata are added into onion_rounting_packets by using the padding space or use more than one hop

Known Limitations

  • No CryptoKitties :'(
    • Non-fungible tokens cannot be moved out of an open channel
  • Possible "blacklist" from vanilla nodes
  • You can receive a specific asset only if you have a channel "colored" with this asset open (with enough liquidity)

RGB on Lightning Network

By Alekos Filini

RGB on Lightning Network

  • 221

More from Alekos Filini