Trade any assets from EVM-compatible chains against BTC on Bitcoin.
A protocol to peg ETH existing on the Ethereum blockchain to "wETH" (wrapped ETH) existing on the Bitcoin blockchain. The peg is trustless. It has a small onchain footprint because proof data is required only in case of an attack. Under the security assumptions attackers are guaranteed to fail and lose money. The peg works for all assets on all major smart contract platforms. ETH is used only as an example here.
- We assume all parties run (SPV) clients for both Ethereum and Bitcoin.
- You as a token holder (or any honest party) watch the Ethereum chain at least once a week.
- We assume the Ethereum miners cannot censor all honest users for an entire week.
- We assume a Colored Coins protocol to represent wETH on top of Bitcoin (e.g. Bitcoin DEX, Omni, or maybe RGB).
The peg-in is simple. Scenario: Alice wants to lock ETH on Ethereum and receive wETH on Bitcoin.
- Alice locks ETH in the peg contract on Ethereum.
- Alice has to reference a particular UTXO for her to use to mint the wETH on bitcoin.
- Alice mints equally much wETH for herself on Bitcoin.
- Alice has to reference the hash of her Ethereum transaction.
- Whenever a Bob receives wETH with a transaction history originating in this genesis, he verifies Alice's lock transaction in Ethereum.
The peg-out is a bit more tricky. Scenario: Carol wants to redeem wETH on Bitcoin for ETH on Ethereum:
- Carol burns her wETH with a burn transaction on Bitcoin.
- Carol makes a claim to withdraw that much ETH from the locking contract on Ethereum.
- Carol has to reference a hash of her burn transaction.
- Carol has to lock a collateral. This is to ensure she gets punished in case her claim was dishonest.
- A challenge period starts (for example one week). Everybody can verify Carol's claim from public data. Every Dave can accuse Carol to be dishonest.
- Dave has to lock a collateral to make an accusation. This is to ensure he gets punished in case his accusation was dishonest.
- If Carol was not challenged before the period expired, then she can withdraw the ETH she claimed without providing any proof.
- Otherwise, if she was challenged, she has to provide a SPV proof proving her entire wETH token history to the Ethereum blockchain.
- If Carol provides a correct proof then she can take the claimed ETH, and Dave loses his collateral to her.
- If Carol doesn't provide a correct proof on time then she loses her collateral to Dave.
This is the basic protocol. The following are optimisations.
Carol's coin history can become quite large. Thus, we want to compress it to save fees. There are a couple of simple improvements possible:
- Use header chain compression for the SPV proofs
- Strip off all witness data from all TXs. (Requires the Colored Coins protocol to be constraint to SegWit TXs)
- Strip off all TXIDs and compute them from previous TXs.
- Require all optional fields like
nVersion
,nLocktime
,nSequence
to have static values. - Store proof data in the contract such that others can reuse them later as basis for their proofs.
- Limit the depth of the coin history.
The following ideas are more sophisticated and are based on the idea to find the point of disagreement with as little proof data as possible. Disclaimer: The constructions are very hand-wavy on the details.
It is possible to define history commitments to be deterministic such that the correct commitment value can be publicly derived from bitcoin's blockchain. This ensures, to resolve a conflict, both parties have to provide only the first part of their histories where they differ from each other. For example, Carol computes her token's history and then splits it up into a sequence of 16 parts. For each part Carol provides a hash in her claim. Dave can disprove her by providing the correct part of the history.
This reduces the required proof data significantly.
The following is an idea to disprove invalid history commitments succinctly. However, for now, we will not combine it with deterministic commitments for the sake of making the core concept easier to understand.
Can Carol commit to a more compact coin history such that it is always possible to disprove an invalid history with a succinct counter-proof?
Output paths are helpful to do that. We can reference every output in the Bitcoin blockchain by its path
path = block_height / transaction_index / output_index
Carol's coin history is a directed acyclic graph originating in genesis outputs. She can commit to her history by describing its graph with a set of output paths and corresponding wETH values. Its consistency can be validated by the contract. This is cheap because it requires no hashing.
We can require Alice to commit to an output path in her ETH transaction. Furthermore, we require that she has to use the corresponding UTXO to mint her wETH on Bitcoin. This ensures the paths of all genesis outputs are known to the Ethereum contract. So, Carol's history has to originate in those genesis paths.
Carol can encode a commitment to a coin history with hundreds of transactions in about 2kB. Most importantly, this commitment allows others to succinctly disprove an invalid history with public data.
Assuming the underlying Colored Coins protocol is sufficiently simple and explicit, Dave should be able to disprove an invalid coin history with only a single bitcoin transaction and an inclusion proof for it. Merkle proofs play nicely together with output paths as they implicitly proof the transaction's index. A commitment to a block's height is in its coinbase output (see BIP34). Thus, output paths are anchored into the proof-of-work of SPV proofs. Verifying Bitcoin SPV proofs on other chains has been researched extensively.
Ideally, Ethereum should be aware of bitcoin's full headers chain. There have been projects trying to do that but it seems like they turned out to be too expensive.
- The protocol works with any asset on any blockchain that can implement the peg-out contract. For example, any ERC-20 token, or assets on Binance Chain, Cardano or Solana.
- In theory,
OP_CAT
would suffice to implement the peg even in Bitcoin Script. Thus, it should be possible to implement the peg on Liquid or Bitcoin Cash because they've activated this opcode in their Bitcoin Script dialect. - In combination with the Bitcoin DEX protocol this peg allows to trade any shitcoin against BTC in a cypherpunk way.
- Confidential transactions might be compatible if there's a way to verify range proofs on EVM.