Internet Computer Association

DFINITY Foundation

ICP Maximalist Network

cycledao.xyz

Chain Key Bitcoin Ledger on the Internet Computer



# Summary

The goal is to have a Bitcoin ledger that makes use of the Bitcoin integration on the IC to bring "Chain Key Bitcoin", referred to as ckBTC in this proposal, to the Internet Computer. Unlike standard "wrapped" Bitcoin solutions, this ledger will not depend on any bridge between the Bitcoin network and the Internet Computer.

If this functionality is built, it will be possible to exchange BTC for ckBTC and vice versa at a 1:1 rate as well as trade ckBTC at the speed of the Internet Computer.

To vote YES on this proposal means that you agree with the plan to build, launch, operate this functionality on the Internet Computer.

If this proposal fails, then this design will not be implemented and the community will go back to the drawing board.

## Key people involved

Manu Drijvers, Mario Pastorelli, Thomas Locher

Timeline for this community-wide design discussion

* 1-pager posted on the forum for review: February 3, 2022
* Draft plan for feature posted on the forum for review: March 15, 2022
* Community conversation with Mario Pastorelli and Thomas Locher: March 16, 2022
* NNS Proposal submission: March 17, 2022, 15:00 UTC
* NNS Proposal expiration: March 19, 2022, 15:00 UTC

If NNS Motion Proposal passes, implementation + deployment target: Q3 2022.

## Design doc for the community:

You can also view a summary of the design here: [Proposed design to review and vote on](https://forum.dfinity.org/t/feedback-wanted-wrapped-bitcoin-ledger-on-the-internet-computer/10681/66?u=thlo).

# NNS Proposal: Chain Key Bitcoin Ledger on the Internet Computer

# Objective

The goal is to introduce a Bitcoin ledger on the Internet Computer based on the Bitcoin integration feature and Chain Key technology.

While the name is not set in stone, we call it the Chain Key Bitcoin (ckBTC) ledger in this design because it is one of the proposed names that received mostly positive feedback.

The ledger will make it possible to trade ckBTC at the speed of the Internet Computer at low cost. Moreover, it will offer mechanisms to convert BTC to ckBTC and vice versa, at a 1:1 rate. Thus, the Chain Key Bitcoin Ledger complements the Bitcoin integration functionality, simplifying the use of Bitcoin on the IC.

# 1. Proposal

## Design

The ckBTC functionality is introduced in the form of two new canisters:

* The ckBTC Ledger is an instance of a ledger, handling ckBTC transfers and managing account balances.
* The ckBTC Minter holds all Bitcoin of ckBTC holders and is in charge of issuing mint and burn calls to the ckBTC Ledger.

### ckBTC Ledger

The API of the ckBTC Ledger will be specified at a later stage. It will offer functions to query balances and transfer funds.

### ckBTC Minter

The ckBTC Minter will offer the following functions.

`get_btc_address(subaccount: vec nat8) -> (String);`

The function deterministically computes a Bitcoin address based on the ckBTC Minter’s main Bitcoin address and the caller’s principal ID, which is an implicit parameter of the function, and the provided subaccount.

Specifically, starting from the ckBTC Minter’s default key, BIP-32 key derivation is used to derive a key using the caller’s principal ID and the provided subaccount. The returned address is derived from this key.

Note that it is possible for a user to derive this Bitcoin address herself/himself.

`get_withdrawal_account() -> (AccountIdentifier);`

The function deterministically computes a ckBTC Ledger account ID based on the principal ID of ckBTC Minter and the principal ID of the caller. The ckBTC Minter burns the ckBTC transferred to this account when the owner calls retrieve_btc to retrieve the same amount in bitcoin.

`update_balance(subaccount: vec nat8) -> (UpdateBalanceResult);`

The function instructs the ckBTC Minter to update the ckBTC balance of the caller. Specifically, the ckBTC canister checks if there are new UTXOs associated with the Bitcoin address derived from the caller’s principal ID and the provided subaccount. If there are such UTXOs, the equivalent amount is minted in ckBTC and made available to the caller in the given subaccount.

This function must be invoked after sending bitcoin to the ckBTC Minter because the ckBTC Minter cannot know for which derived accounts it will receive funds.

`retrieve_btc(amount: Bitcoin, fee: opt Bitcoin, address: String) -> (RetrieveBtcResult);`

The function instructs the ckBTC Minter to send the given amount of Bitcoin to the provided Bitcoin address, burning the equivalent amount of ckBTC tokens. Note that at least the given amount must be transferred first, in ckBTC, to the caller’s withdrawal account. The withdrawal account is a ckBTC Ledger account under the control of the ckBTC Minter. The subaccount is derived deterministically from the user’s principal ID.

The optional fee parameter defines the fee to be used in the Bitcoin transaction that transfers the Bitcoin to the given Bitcoin address. If no fee is provided, the ckBTC Minter uses a standard fee, obtained through the Bitcoin integration fee API.

The ckBTC tokens are burned before the Bitcoin transaction is confirmed. If a transaction does not appear in a block, the user has the option to resubmit the transaction using the resubmit_retrieve_btc function below.

`get_minimum_fee() -> (Bitcoin) query;`

The function returns the minimum expected fee when providing a custom fee in the retrieve_btc function call.

The ckBTC Minter uses the Bitcoin integration fee API to derive this fee.

`resubmit_retrieve_btc(request_id: nat64, new_fee: Bitcoin) -> (ResubmitRetrieveBtcResult);`

The function instructs the ckBTC Minter to resubmit a Bitcoin transaction for a previous request, updating the fee. This function is intended to be used for transactions that are stuck because the fee was set too low.

The new fee must be higher than the last fee in the transaction associated with this request, increasing the fee according to [BIP-125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki).

# 2. Risks

If the ckBTC Minter or ckBTC Ledger is compromised, the funds provided in Bitcoin could be lost. The current plan is to deploy both canisters on a large system subnet, similar in size to the NNS, to mitigate this risk.

# 3. Alternative Designs

An alternative design would be to have a single canister acting as the ledger and custodian. Since we have a well-tested ledger available, having two separate canisters is considered to be a safer design. Moreover, reusing the existing ledger reduces the implementation effort.

# 4. Roll-out Plan

Once implementation and testing work has been completed, the plan is to deploy the two canisters to a system subnet, at which point the functionality becomes available.

If the ckBTC functionality is observed to behave as intended, the controller will be changed to the NNS, ensuring that any future changes can only happen with the approval of the community.

# 5. Timeline

If the NNS motion proposal is accepted, development will start right away. Proper testing will only be possible once the Bitcoin integration feature is operational. As a result, we plan to release the ckBTC functionality in Q3 2022.

# What we are asking the community

- Vote YES or NO on the proposal

Previous threads: 
* https://forum.dfinity.org/t/feedback-wanted-wrapped-bitcoin-ledger-on-the-internet-computer/10681/66?u=thlo 

