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)