Generic Assets on Bitcoin

Alekos Filini (@afilini) - Developer at BHB Network

Overview

Chapter 1 - How does Bitcoin work?

Chapter 2 - Brief history of assets on blockchains

Chapter 3 - Why RGB?

Chapter 4 - The RGB protocol

How does Bitcoin work?

Chapter 1

Bitcoin

A purely peer-to-peer version of electronic cash that allow online

payments to be sent directly from one party to another without going through a

financial institution. [...]

The network timestamps transactions by hashing them into an ongoing chain of

hash-based proof-of-work, forming a record that cannot be changed without redoing

the proof-of-work.

Bitcoin

A purely peer-to-peer version of electronic cash that allow online

payments to be sent directly from one party to another without going through a

financial institution. [...]

The network timestamps transactions by hashing them into an ongoing chain of

hash-based proof-of-work, forming a record that cannot be changed without redoing

the proof-of-work.

  • There's no "official", centralized entity which controls Bitcoin
  • Data are shared in a distributed (redundant) way among network participants

 

  • Basically impossible to "stop" Bitcoin

Bitcoin

A purely peer-to-peer version of electronic cash that allow online

payments to be sent directly from one party to another without going through a

financial institution. [...]

The network timestamps transactions by hashing them into an ongoing chain of

hash-based proof-of-work, forming a record that cannot be changed without redoing

the proof-of-work.

  • "Be your own bank"
  • Don't have to ask for permission to anyone

 

  • No way for a third-party to censor your transactions

Bitcoin

A purely peer-to-peer version of electronic cash that allow online

payments to be sent directly from one party to another without going through a

financial institution. [...]

The network timestamps transactions by hashing them into an ongoing chain of

hash-based proof-of-work, forming a record that cannot be changed without redoing

the proof-of-work.

  • The entire network can agree on whether a transaction A was done before or after transaction B
  • Even if there are noticeable network latencies involved

 

  • Don't need a central "coordinator", fully P2P

Bitcoin

A purely peer-to-peer version of electronic cash that allow online

payments to be sent directly from one party to another without going through a

financial institution. [...]

The network timestamps transactions by hashing them into an ongoing chain of

hash-based proof-of-work, forming a record that cannot be changed without redoing

the proof-of-work.

  • There's thermodynamic cost to write data to the blockchain
  • The work keeps accumulating - changing data requires redoing the work

 

  • Harder to attack Bitcoin - you would need money, time, energy, hardware

Bitcoin

Terminology

  • Transaction = a digital entity which destroys one or more digital banknotes and creates one or more new digital banknotes, while making sure that sum(out) <= sum(in)
  • Output = a digital banknote created by a transaction
  • Input = a digital banknote spent by a transaction

Assumptions

  • Blockchain = a magic black box that makes sure that outputs are spent only once, and keeps track of them

A Bitcoin Transaction

Brief history of assets on blockchains

Chapter 2

Disclaimer

  • We think that most of the tokens out there are useless
  • We don't want to encourage scams
  • But still..
  • We think that this is a really cool research project
  • And also a solid platform in case you really want to issue a token

Colored Coins

  • Very simple concept: let's "color" a Bitcoin output so that it's unique
    • Whoever owns the output, owns the tokens
  • Meta-data written in some "free" areas of the transaction
  • Cons:
    • Everything is public
    • Hard to "decouple" tokens and the underlying Bitcoin(s)
    • Limited amount of space means limiting the data embedded into the tx

"<Token>coin"

  • We need more flexibility: let's create a new blockchain for our token!
  • Easy to change if you need to
  • Cons:
    • Very unstable/unsafe: low hash-rate
    • High social friction

Asset-enabled Blockchains

  • Let's keep flexibility, while also "aggregating" hashing power
  • Basically the Ethereum model with Solidity
  • Cons:
    • It's actually not solid at all: "generic-ness" is a bug, not a feature!
    • Even less scalable than a blockchain: everybody has to validate everything

Asset-enabled Side-chains

  • Let's create a structure similar to a blockchain, but with a "federation" of miners
  • People can freely move Bitcoin in and out of the side-chain
  • People can issue asset on your side-chain
  • Can support ZKP stuff
    • Like Confidential Assets on Liquid
  • Cons:
    • Not fully decentralized, there's a federation

Why RGB?

Chapter 3

Why RGB?

  • Bitcoin is safe
    • Huge hashing power
    • Most "brain power" invested
    • (relatively) long history
  • Improve privacy by hiding data to the public
    • Metadata are kept "off-chain" and moved independently
  • More scalable
    • You don't have to store/verify everything
  • Easy to change/upgrade without consensus
    • It's not a global, consensus-based, network

The RGB protocol

Chapter 4

The protocol

  • Basically an improved colored coin protocol
    • Hence the name!
  • Makes use of math tricks to hide data and save bytes
  • Only validate what you care about
  • Limited set of "instructions" and limited attack surface
    • No scripting system (we don't need it, we can reuse Bitcoin's one!)

Commitment Scheme

  • AKA: how do we write "extra" data in a Bitcoin transaction
  • The blockchain is basically immutable, so writing informations into it makes them immutable too
  • One additional "dummy" output: OP_RETURN
  • Hide data into a public key: Pay-to-contract
    • Take an EC point (ECDSA pubkey)
    • Calculate P_new = P_orig + h( data || P_orig) * G
    • You can later prove that data is committed by showing P_orig 
OP_RETURN <data>
OP_DUP OP_HASH160 <h(P_new)> OP_EQUALVERIFY OP_CHECKSIG
  • We start from a colored coin protocol
  • Move colored coins by adding meta-data in OP_RETURNS
  • All readable and verifiable by everyone

Bitcoin TX

RGB

  • We can move the meta-data off-chain, and replace them with an hash
  • Verified only by the receiver and future owners
  • A little bit more plausible deniability/privacy
  • Allows to encode tons of data

RGB

  • One more thing...
  • Use pay-to-contract instead of OP_RETURNS
  • Even more plausible deniability
  • Save a few bytes and satoshis in fees

RGB

How to make a transaction

  1. Make a Bitcoin transaction
    • It could pay whoever you want, no need to pay the token receiver
      • Allows you to decouple tokens and Bitcoins
      • More privacy!
  2. Create the corresponding proof
    • It will contain data about who to pay
      • It could be a known, existing output on the blockchain
      • Or a new output you are creating in this TX
  3. Commit to the proof in your transaction
  4. Broadcast the transaction

Pseudocode

{
  "vin": [
    {
      "txid": "......",
      "vout": 0
    }
  ],
  "vout": [
    {
      "amount": 10,
      "scriptPubKey": "OP_RETURN <h(proof)>"
    }
  ]
}
{
  "vout": [
    {
      "asset_id": "STARBUCKS_COIN",
      "amount": 100,
      "type": "NEW_OUTPUT",
      "index": 0
    }
  ]
}

Why can't I change my mind later?

  • The transaction itself cannot be changed
    • We assumed the blockchain is immutable
  • It contains the hash of your proof
  • You would need to find a collision
  • Little bit more complex if we use pay-to-contract
    • Rely on some EC math properties

How to verify a transaction

  1. Make sure the transaction has been confirmed by the Bitcoin network
  2. Download the chain of proofs up to the "origin" (the one who issued the asset)
  3. Verify all the proofs in between and the commitments
  4. Verify the amounts of each transaction
  5. If everything checks out you are good to go!

Pseudocode

def verify_rgb_proof(proof):
    bitcoin_transaction = bitcoin.get(proof.bitcoin_txid)
    assert bitcoin_transaction.valid()
    
    assert bitcoin_transaction.verify_commitment(proof)

    if proof.type == 'ISSUANCE' and len(proof.inputs) == 0:
        return True

    assert sum(proof.out_value) == sum(proof.in_value)
    assert all([verify_rgb_proof(input) for input in proof.inputs])

    return True

Useful Links

Specifications: https://github.com/rgb-org/spec

Alpha code: https://github.com/rgb-org/rgb

Made with Slides.com