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...

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)