Bringing BTC on Ethereum

A deep dive into tBTC and Ren and how they plan to bring BTC onto Ethereum

May 7, 2020

Bitcoin 101

Bitcoin works through the UTXO model, for those of you who don’t know what that means. It goes a little something like this:

UTXO stands for Unspent Transaction Output or in simple english, unspent transactions
The amount of Bitcoin you have is simply an aggregate of all the UTXOs you own as a user
When you “spend” or “transfer” Bitcoin, you’re actually aggregating many UTXOs as inputs and then generating a new set of outputs where the outputs are owned by the destination user

Okay, so now that we have that out of the way. Let’s dig a bit deeper into how a UTXO looks/works under the hood. The X key things you need to care about in this diagram:

Inputs - a reference to all the UTXOs you would like to spend
Outputs - the new outputs to be generated from the provided inputs
Locking script - a set of conditions required to spend these UTXOs directly

A standard transaction will set the locking script to specify that only the recipient can spend these next set of UTXOs via the following script:

ScriptPubKey = OP_DUP OP_HASH160 <hash160(pubKey)> OP_EQUAL OP_CHECKSIG

Unless the spender of these new outputs is equal to the public key specified by the sender, they can’t spend these UTXOs. However here lies the core problem of Bitcoin, the expressiveness of this locking script is extremely limited and all parameters need to be set in advanced. You can’t determine any conditions at the time of execution.

High Level

Okay so now that we’ve got that out of the way, let’s talk about what we need to do for any kind of implementation to bring BTC to Ethereum and the challenges faced so when we dig into Ren and tBTC we can get a clearer idea of how they solve various issues in their respective systems.

You have a user holds BTC and wants to bring it onto Ethereum
This user will deposit their BTC to some address. Problem #1: whatever address they deposit the money to, it will be something that isn’t in their control and their funds can be stolen/moved.
We then need to prove that ownership of the BTC belongs to this new user and submit that proof to an Ethereum smart contract. Problem #2: proving the events of one chain on another chain
This Ethereum smart contract will need to verify and then mint some kind of tokenised BTC on Ethereum
At any point in time, the user can take a tokenised BTC, burn it and receive one real BTC on the Bitcoin chain. Problem #3: the user, at all times, must be able to get real BTC for his tokenised BTC.

Keys

Most bridging BTC to Ethereum need a way to keep custody of BTC while it’s locked up. Since you want this as decentralised as possible, you want custodians to be chosen at random (to prevent colluding). This leads us to the area of key generation schemes.

The most common key sharing scheme know by people in crypto is Shamir’s Key Secret Sharing scheme. Here’s how it works:

A master/owner generates a private key (they explicitly hold this)
Shamir key secret sharing is used to split the private key into 2 of 3 parts
If 2 of those secret parts are recovered, the full private key can be regenerated!

Shamir Key Secret sharing works great if you trust the person (most likely yourself), however if you were to trust that the master didn’t fully destroy the private key then you’re at risk of losing your funds. This doesn’t work great if you want to trust a group of custodians to hold your Bitcoin in a decentralised network…

Introducing Threshold Signatures! The elegance of this scheme is hard to understate. This scheme relies on something known as Multi Party Computation at its core where essentially you can do math on encrypted values without knowing the values themselves using homomorphic encryption. eg.

encrypted(1) + encrypted(2) = encrypted(3)

Okay cool math, nerd - but how does this help with key generation? Without going into too much math we could create a similar equation where rather than numbers we can use certain information to sign any piece of information with the same private key without anyone ever seeing the private key explicitly! I know, trippy. I’ll explain below:

Participants in the scheme start off with “secret shares” that correspond to a private/public key pairs. The scheme will specify how many shares are required to be utilised.
Secret shares aren’t private keys but rather pieces of information that when added together can be used to sign off as the private key without any single party knowing the the private key
When a piece of data needs to be signed off using the scheme’s private key, a certain number of participants need to sign off the information otherwise the output signature won’t be correct

Threshold signature generation is super useful since you can add/remove participants from a scheme without changing the key-pair itself. You can have various implementations of this as well. Identifying participants around who did or didn’t perform an action can also be complex.

This is a massive oversimplification and doesn’t cover some of the intricate math but is simply meant to be a high level of how the magic works at a comprehendible level.

tBTC

In every crypto race, there’s the east and the west. tBTC is a project of the west for sure. They’ve got all of Silicon Valley’s top backers with a fresh $7m in their Series A a month or so ago. I’ll explain their approach below and then summarising how they solve the problems outlined above.

User who wants to deposit BTC will request “signers” to create a deposit address to deposit their BTC. They can deposit lots of .1, .25 or 1 BTC. In order to create a request users need to provide a small deposit up-front to cover costs of initiating the transaction.
Keep Network will use a multi-party computation to select 3 random signers from the group. These signers will be chosen to create a Bitcoin deposit address and an Ethereum smart contract owned by the same private key. The smart contract will also create an empty TDT (ERC721 token).
Signers are required to deposit 150% of the value of the BTC denominated in ETH. This collateralisation ratio needs to be maintained at all times.
After enough confirmations, a simple payment verification (SPV) proof can be generated and submitted to the Ethereum deposit address. Upon success, the TDT will have the SPV attached to it and link the user’s UTXO to that particular TDT. You can read more about SPVs over here: https://docs.keep.network/tbtc/appendix/spv/
The TDT with a valid SPV proof can now be used to mint a valid TBTC token on Ethereum main-net.
In order to redeem the tBTC they can relinquish their TDT, pay signer fees, broadcast their transaction and signers can then receive their funds back.

What are the benefits of tBTC’s approach?

Users can link a TDT to the exact UTXO it was claimed for. This property means that you can get the *exact* Bitcoin(s) that you deposited. Use case could be ensuring you don’t get blacklisted UTXOs.
Depositors need to have 150% of the value of BTC in ETH at all times. You can be assured that collusion isn’t in their best interest.
You can reason about the security of the system by weighing the total amount of ETH collateral held by signers versus BTC in custody.

What are the downsides of tBTC’s approach?

You need 150% of collateral. If it goes down you lose your ETH, if it goes up you get a small amount of fees. The risk pay-off isn’t the best. It’ll be questionable who will sign up for this risk/reward equation.
Users need to specify lot sizes and can’t use custom amounts

Ren

RenVM is the project from the East. Originally started in 2017 with a raise to the tune of $30m-$40m. Ren is actually a Proof of Stake network where you have shards of 129 nodes (referred to as Darknodes). In order to become a Darknodes you need to stake a certain amount of REN tokens. Enough context, let’s get into the meat of it:

Each node is required to stake REN tokens in order to be part of a shard. A shard will be responsible for generating a set of private/public key pairs which users can generate for users to deposit BTC.
Users choose a shard that they’d like to have as custodians
Part of generating a key pair requires the authority of the “greycore” - a set of trusted community members. In order for a transaction to go through both the Darknodes and Greycore need to sign off on transactions
Users can then deposit BTC to a script which can only be spent by the shard’s key pair
The UTXO is then sent to a SPV proof relayer on the Ethereum network where the RenVM can validate if the UTXO is indeed under custody of the REN network
Upon verification of the UTXO, RenVM generates a valid signature which can then be taken to the Ren ERC20 BTC contract on Ethereum and mint a valid Bitcoin token
In order to redeem a Ren BTC then need to burn the ERC20 token and specify a redemption address. The redemption process requires the Darknodes and Greycore to sign off and execute on.

What are the benefits of Ren’s approach?

Dark Nodes need to just hold a certain amount of REN tokens rather than having the same collateral value.
Since nodes aren’t over collateralised this makes it cheaper to bring an asset from another chain to Ethereum and vice versa
Users can deposit any amount of BTC, not confined to “slots”

What are the downsides to Ren’s approach?

The value of REN tokens could be less than the BTC held in custody. This is slightly harder to achieve since shards are shuffled every 24 hours but still worth mentioning.
You can’t redeem the exact BTC you deposited since the network doesn’t actively track/store it.

What are some questionable choices to Ren’s approach?

The use of Greycore making the network somewhat permissioned (members can be voted and removed by token holders down the line). I won’t say it’s a bad thing since it’s unlikely that any of the members will cheat but for the decentralisation maximalists, Ren may raise some eyebrows. Conversely those that don’t care about strong decentralisation guarantees might not care.
They’re using their own MPC algorithm which is a somewhat risky move considering that these things are highly complex and only those that have stood the test of time can be trusted

Verdict

Creating high quality content on a consistent basis is really demanding. By upgrading to premium you’re supporting me. Read more about my decision and why DeFi Weekly is switching to a Freemium model:

https://defiweekly.substack.com/p/defi-weekly-premium

Kerman Kohli