Skip to content

Conversation

siran
Copy link

@siran siran commented Dec 21, 2024

Abstract

This proposal defines eBTC: a trustless, one-way bridge allowing BTC to enter Cardano as a native token. Users burn BTC on Bitcoin and present cryptographic proofs (NIPoPoW/SPV) to a Cardano smart contract, which mints a corresponding amount of eBTC. This solution removes reliance on custodians and oracles, enabling purely decentralized conversion and unlocking BTC’s liquidity for Cardano DeFi.


(latest document) - @siran please keep updating this link whenever pathname changes.

@rphair rphair added the Category: Tokens Proposals belonging to the 'Tokens' category. label Dec 21, 2024
@rphair rphair changed the title Cps 1856 - eBTC – A Trustless BTC Bridge on Cardano CIP-???? | Trustless BTC Bridge Dec 21, 2024
@rphair
Copy link
Collaborator

rphair commented Dec 21, 2024

I'm converting this into Draft review status until it complies with the CIP format as described in CIP-0001 (#955) with about 100 examples of CIPs in the repository to imitate if there is any uncertainty. See here & the following "checklist" page for factors that make a good CIP: https://github.com/cardano-foundation/CIPs/wiki/2.-CIPs-for-Reviewers-&-Authors

The term CPS was originally in the title although this appears to be a plan for a particular method. @siran if you think this is instead a class of possible approaches to BTC wrapping on Cardano that could generate multiple CIPs, please say so here and we'll try to get you started converting your draft into a proper CPS draft.

@rphair rphair marked this pull request as draft December 21, 2024 11:13
@siran
Copy link
Author

siran commented Dec 21, 2024

Thanks so much for your comments and patience. This is my first attempt at a CIP. So i'll check and imitate previous CIPs.

I do not know if this is a CIP or a CPS. Nor if it would devolve into multiple CIPs. I would be happy just with it being discussed :).

I'll try to read around to meet standards. Tried Discord server but didn't get response.

Thanks.

@rphair
Copy link
Collaborator

rphair commented Dec 21, 2024

@siran it's still not in the form of CPS a which has different sections than a CIP. If you could please refer to it consistently as a CIP (as opposed to this Discord comment), and change the title of your containing directly to something like CIP-XXXX or CIP-BTC-bridge, it will help potential reviewers.

Also you should include the Cardano Forum post in the CIP header (https://forum.cardano.org/t/ebtc-a-trustless-btc-bridge-on-cardano/141117) now that discussion has emerged there.

I'll leave it as a CIP in the PR title since that's definitely what it appears to be. FYI here is the specification for the CPS (which I don't think it's in your best interest to use): https://github.com/cardano-foundation/CIPs/blob/master/CIP-9999/README.md


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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Tokens Proposals belonging to the 'Tokens' category.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants