Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CIP-???? | Trustless BTC Bridge #955

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from
Draft

CIP-???? | Trustless BTC Bridge #955

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
b66407e
CPS-0017
siran Dec 21, 2024
e241183
CPS-1856
siran Dec 21, 2024
fad2439
CIP rewrite
siran Dec 21, 2024
8ad8a5e
eBTC for Cardano - CPS - smart bitcoin
siran Dec 21, 2024
7fc79f6
improving CIP, extending to include two-way bride
siran Dec 22, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
167 changes: 167 additions & 0 deletions CPS-1856/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,167 @@
---
CIP: CIP-XXXX
Title: eBTC: A Trustless BTC Bridge on Cardano
Authors:
- An <[email protected]>
Discussions-To:
- https://github.com/siran/CIPs/pull/1856
- https://forum.cardano.org/t/ebtc-a-trustless-btc-bridge-on-cardano/141117
Status: Draft
Type: Standards
Created: 2024-12-21
License: CC-BY-4.0
---

## Abstract

This proposal defines eBTC: a trustless mechanism for moving Bitcoin (BTC) value onto Cardano as a native token, unlocking BTC liquidity for Cardano DeFi. Originally conceived as a **one-way, burn-and-mint** design, this CIP also explores a more advanced **two-way** approach using on-chain key management. The one-way approach involves burning BTC on the Bitcoin network, presenting cryptographic proofs (NIPoPoW/SPV) to a Cardano smart contract, and minting a corresponding amount of eBTC. The two-way extension allows redeeming BTC by carefully managing a unique Bitcoin wallet private key on-chain. Both approaches aim at allowing BTC to benefit from Cardano’s advanced smart contract functionalities.

## Motivation

Bitcoin (BTC) remains the most recognized and liquid cryptocurrency in the blockchain ecosystem, yet it lacks robust smart contract capabilities on its native chain. Existing wrapped BTC solutions on other chains typically rely on centralized custodians or oracles, introducing trust and counterparty risk.

A trust-minimized bridge helps the Cardano ecosystem tap into BTC’s liquidity while leveraging Cardano’s smart contracts for DeFi applications. This CIP:

- Removes reliance on external custodians.
- Avoids complex bridging or cross-chain custody solutions.
- Enables BTC to participate in Cardano-based lending, decentralized exchanges (DEXs), and other DeFi protocols.

Initially, a simpler one-way approach was proposed: burning BTC to an unspendable address on Bitcoin, then issuing eBTC on Cardano. Subsequent discussions have revealed that a more complex but feasible **two-way** version could be built, where the Cardano contract generates and holds (in encrypted form) the private key of a **unique** Bitcoin address. This key is only released once eBTC is burned, allowing BTC to be reclaimed without trusting a centralized custodian.

## Specification

### Overview of Two Options

1. Option A: One-Way Burn-and-Mint (Simpler)
2. Option B: Two-Way On-Chain Key Management (Advanced)

Below, we detail the simpler, one-way process first (as originally conceived), followed by an extended specification for a fully on-chain, two-way design.

---

### Option A: One-Way Burn-and-Mint

1. Burning BTC on the Bitcoin Chain
- Burn Address: Define a standard, provably unspendable Bitcoin address, such as one using an `OP_RETURN` script or a well-known “burn” address.
- Burn Transaction: The user sends BTC to this burn address, removing those BTC from circulation.

2. Proof Generation (NIPoPoW/SPV)
- The user (or an off-chain service) constructs an SPV or NIPoPoW proof verifying that the burn transaction was included in a valid Bitcoin block on the main chain.
- This proof, along with relevant block headers, is submitted to Cardano.

3. Cardano Smart Contract Verification
- A Plutus contract confirms the proof corresponds to a valid burn transaction and that the transaction has sufficient confirmations to mitigate reorg risks.
- Upon success, the contract mints an equivalent amount of eBTC (1:1) for the user on Cardano.

4. Usage of eBTC
- eBTC can be used for Cardano DeFi (lending, DEX trading, liquidity provisioning, etc.).
- Since BTC was burned, there is no “redemption” back to Bitcoin in this one-way model.

5. Key Benefits
- Extremely simple, minimal trust.
- No need to store or manage Bitcoin keys.
- Guaranteed supply limit: the eBTC supply is constrained by the total BTC burned.

---

### Option B: Two-Way On-Chain Key Management

The following specification describes an **on-chain** approach that allows redeeming BTC after eBTC has been minted, without a third-party custodian. It utilizes a unique Bitcoin address per bridging session. The contract encrypts the private key so that no one can move the BTC unless eBTC is first burned.

1. Unique Bitcoin Address Generation
- The Cardano contract deterministically or randomly generates a fresh Bitcoin public/private keypair on-chain.
- It displays only the public portion to the user.
- The private key remains encrypted within the contract’s storage so that no entity (not even the user) can access it yet.

2. Locking BTC to Mint eBTC
- The user sends BTC to the generated Bitcoin address.
- Using NIPoPoW or SPV proofs, the user shows the Cardano contract that the BTC is confirmed to be at that address.
- The contract mints eBTC (1:1 with the locked BTC) and sends it to the user on Cardano.
- Because the private key to this Bitcoin address is inaccessible, the BTC cannot be moved on the Bitcoin chain until eBTC is destroyed (burned).

3. Burning eBTC to Redeem BTC
- To reclaim the locked BTC, the user burns eBTC by calling the contract with a “redeem” function.
- Once eBTC is burned, the contract may reveal the encrypted key only after eBTC is burned.
- User can then use keys to move its BTC.

4. Security Principles
- The private key remains encrypted and is never accessible until eBTC is burned.
- No double-spend is possible: the user cannot move BTC on Bitcoin while still holding eBTC on Cardano.
- Once eBTC is destroyed, the user can spend the BTC.

5. On-Chain Feasibility
- All logic (generation of unique addresses, encryption, gating conditions) is handled on Cardano.
- Proof of BTC locking uses standard SPV or NIPoPoW.
- Broadcasting the Bitcoin transaction is done by the Bitcoin chain.

6. Considerations
- This approach is more complex than a straightforward burn-and-mint.
- The contract must implement robust cryptography to generate and store the private key securely.
- The Cardano environment must support or expose the cryptographic functions (ECDSA for Bitcoin, encryption, etc.) necessary to sign a Bitcoin transaction on-chain or to release a private key in a secure manner.

---

## Rationale

1. Why a Simple One-Way Bridge (Option A)?
- Minimal complexity: only requires proving a burn on Bitcoin and minting eBTC on Cardano.
- Removes custodian risk entirely, with no need for advanced key management.
- Feels natural for permanent “migration” of BTC into Cardano DeFi.

2. Why Offer a Two-Way Alternative (Option B)?
- Allows users to exit back to Bitcoin if desired, removing the permanent burn condition.
- Achieves decentralized custody by storing the Bitcoin private key in the Cardano contract itself.
- Avoids reliance on multi-signature federations or centralized custodians, maintaining trust-minimized principles.

3. Trade-Offs
- The two-way approach is feasible with proper cryptographic capabilities and robust contract code.
- One-way bridging is simpler and presents fewer attack surfaces.
- Depending on user requirements (e.g., “I want to come back to Bitcoin eventually”), Option B may be worth the added complexity.

---

## Backward Compatibility

- The CIP does not alter Cardano’s consensus or ledger rules; it proposes new smart contracts and token policies.

---

## Reference Implementation

1. On-Chain Key Generation
- For Option A (One-Way): no key management is needed.
- For Option B (Two-Way): the contract could generate a Bitcoin keypair on-chain, store it encrypted, and control its release or usage.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how can a contract manage keypairs on-chain and keep private key secret?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for your interest.

would this work?

A contract alone typically cannot hold a private key “secret” on a fully transparent blockchain. Instead, one must use threshold cryptography or multi-party computation (MPC), where the key is split among multiple participants/nodes. Each piece is useless by itself, so no single party or on-chain entity has the entire private key. The contract effectively “manages” the key by coordinating partial signatures from these participants. Another approach is to store an encrypted key on-chain, and only decrypt it in a secure off-chain or MPC environment when the contract logic calls for a signature. In both cases, the actual private key bits are never revealed in plaintext on the public ledger.

(cBTC is a better name)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Proposed Approach

  1. Key Generation & Distribution

    • The bridging contract generates a Bitcoin key, then splits it into multiple fragments (e.g. via Shamir’s Secret Sharing).
    • Each fragment is encrypted for a specific stake pool operator, using that operator’s on-chain public key.
    • The contract publishes these encrypted fragments on-chain, so nobody sees the raw private key.

  2. Minting cBTC

    • User deposits BTC to a 2-of-2 address (part user key, part bridging key).
    • A proof (e.g. NiPoPoW) is submitted to the bridging contract.
    • The contract “mints” cBTC tokens on Cardano for that user, representing the locked BTC.

  3. Burn-to-Release Process

    • To unlock the BTC back on Bitcoin, the user burns their cBTC on Cardano.
    • The contract detects this burn event and proceeds to reassemble its share of the private key.

  4. Recombining Key Fragments

    • Each stake pool operator retrieves its own encrypted fragment from the chain, decrypts it locally (with its private key), and provides a partial signature or partial decryption to the contract.
    • Once the threshold (e.g. t-of-n stake pools) has cooperated, the contract can reconstruct its share of the BTC key on-chain.

  5. Completing the BTC Spend

    • The contract then co-signs (with the user’s key) a transaction that releases BTC to the user’s chosen address on Bitcoin.
    • This happens automatically as soon as enough stake pool operators submit valid partial decryptions.

Why It’s Trustless & Automated

  • No single stake pool operator or the contract itself holds the entire private key; collusion of at least t is required.
  • The bridging contract enforces “burn cBTC first” before releasing key material to sign the BTC transaction.
  • Stake pools already run infrastructure for Cardano, so they can securely manage key fragments in a similar automated fashion.
  • Everything from fragment distribution to partial-sig aggregation is orchestrated by the contract, on-chain, ensuring transparency and preventing unauthorized BTC spends.

I was not sure about this, so additional info:

How the User Gets a Deposit Address & Provides a NiPoPoW

  1. Contract Generates Address

    • First, the user calls the bridging contract on Cardano asking for a unique deposit address on Bitcoin (e.g., a 2-of-2 multi-sig address).
    • The contract creates this address by combining the user’s public key with the contract’s bridging key.

  2. User Deposits BTC

    • The user sends BTC to that newly generated address.
    • Once enough confirmations have passed, the user (or any off-chain service) can gather a NiPoPoW (Non-Interactive Proof of Proof-of-Work) that proves “X BTC was deposited to that address.”

  3. User Submits NiPoPoW

    • The user returns to the Cardano contract and submits the NiPoPoW proof, indicating the transaction ID, the address, and the confirmed deposit.
    • The bridging contract verifies the proof on-chain to confirm the BTC is locked at the multi-sig address.

  4. Contract Mints cBTC

    • After successful verification, the contract mints the corresponding amount of “cBTC” for the user on Cardano.

Thus, the user first obtains a fresh deposit address (step 1), sends BTC to it (step 2), then uses NiPoPoW (steps 3–4) to prove that deposit to the bridging contract—no trust in a single custodian required.

the idea is a wip

hope it helps


2. SPV/NIPoPoW Proof Submission
- A module or library for constructing minimal proofs from the Bitcoin blockchain.
- The Cardano contract checks that the proofs reference the correct transaction, block height, and chain of greatest cumulative work.

3. Mint/Burn Mechanism
- Plutus or other Cardano contract language can define the minting policy to issue eBTC upon verifying the proof.
- Similarly, the policy and contract ensure eBTC is burned before Option B’s private key is revealed.

4. Example Workflow
- Option A: (Burn on Bitcoin) → (Prove on Cardano) → (Mint eBTC). No redemption step.
- Option B: (Generate BTC address on-chain) → (User locks BTC) → (Prove and mint eBTC) → (User burns eBTC) → (Contract finalizes Bitcoin transaction to release locked BTC).

---

## Security Considerations

1. For Option A (One-Way)
- The main security concern is accurate verification of the Bitcoin burn transaction.
- Once BTC is burned, it cannot reappear on Bitcoin, ensuring no double-spend.

2. For Option B (Two-Way)
- The contract must store and manage a Bitcoin private key in a way that absolutely prevents premature access.
- Cardano’s contract environment must support cryptographic operations for generating BTC addresses.

3. Common Considerations
- SPV/NIPoPoW proofs need sufficient confirmations to avoid chain reorganizations on Bitcoin.
- eBTC minting policies must strictly bind to the contract logic, preventing unauthorized minting.

---

## Copyright

This CIP is licensed under CC-BY-4.0. Feel free to share and adapt it with attribution.