Direct Integration with Bitcoin

Roadmap
22

Great questions!
Since subnets will be able to hold and control real Bitcoin/Ether, it is of paramount importance to ensure that Bitcoin/Ether are neither lost (for example because the subnet failed and cannot be recovered) nor stolen (for example because sufficiently many node providers collude to extract the secret key material).

The feature “Threshold ECDSA Signatures” is all about making it possible for subnets to hold Bitcoin/Ether in a secure manner. If you’d like to learn more about this feature including security assumptions and guarantees, I encourage you to post your questions directly on the dedicated forum page!

2 Likes
23

Hey folks, I updated the main description with the current timeline.

2 Likes
24

Lol :joy: same here. That’s hilarious.

25

Hey folks,

I just updated the timeline for this feature based on what we currently see as potential engineering scope (within an order of magnitude, and it will get clearer as we get more info).

2 Likes
26

As announced already here in the forum, this feature with the goal of directly integrating with Bitcoin is going through a community-wide voting process. In this post, we present the feature design.

NNS Proposal: Direct Integration with Bitcoin

Main authors: Dieter Sommer, @THLO

Background

Bitcoin is a decentralized digital currency based on an open-source P2P protocol. Bitcoin uses the unspent transaction output (UTXO) accounting model, i.e., transactions create outputs which are used as inputs to other transactions that create new transaction outputs.

Bitcoin is a payment network without support for smart contracts. Smart contract support for Bitcoin would add tremendous value: Smart contracts for Bitcoin would leverage the combined strength of the Bitcoin network as the world’s digital gold reserve and the Internet Computer as a platform for securely and efficiently executing smart contracts. An example class of applications that will become possible with this integration are decentralized finance (DeFi) applications, which can currently be implemented only with wrapped Bitcoin and additional trusted entities on blockchains such as Ethereum. Moreover, Bitcoin could be used for paying for any kind of services on the Internet Computer, which opens up a sheer endless number of application scenarios.

Goals and Requirements

The goal for this feature is a direct integration with the Bitcoin network with the following functionalities:

  • Canisters can directly hold Bitcoin, i.e., the balances of canisters are captured on the real Bitcoin network. These Bitcoin smart contract canisters can run Turing-complete logic and, based on this, decide when to make Bitcoin transactions to other entities such as regular Bitcoin users or other canisters implementing Bitcoin smart contracts.
  • Canisters can create Bitcoin transactions and submit them to be reliably relayed to the Bitcoin network.

A direct integration implies not only that canisters can hold Bitcoin themselves, but also that there are no intermediaries such as bridges introduced into the design.

The intended integration requires the Internet Computer offering the following functionalities to canisters:

  1. Enabling canisters to receive and hold Bitcoin on the Bitcoin network;
  2. Tracking the UTXO set belonging to canisters and enabling canisters to query their respective UTXO set;
  3. Enabling canisters to create Bitcoin transactions and accepting such transactions from canisters to be relayed to the Bitcoin network.

In order to achieve Functionality (1), canisters must be able to have a Threshold ECDSA public key from which their Bitcoin addresses are derived. Threshold ECDSA is a separate feature going through community voting concurrently with this feature. Functionality (2) requires that we ingest Bitcoin blocks into the Internet Computer, validate them, and track the Bitcoin blockchain. Once blocks have a sufficient amount of work in successor blocks on the blockchain, transactions and their UTXOs can be extracted and served to canisters upon request. Functionality (3) depends on the aforementioned Threshold ECDSA feature, which makes it possible for canisters to consume UTXOs. Furthermore, the Internet Computer must establish an outbound communication channel over which an outgoing transaction from a Bitcoin smart contract canister can be reliably relayed to the Bitcoin network.

Design

A high-level overview of the technical design is outlined next. The figure below further illustrates the high-level design.

In the Execution layer of the Internet Computer, we implement a BTC system component that offers the following APIs to query the UTXO set associated with the requesting canister’s public key and submit transactions to the Bitcoin network, respectively:

  • get_utxo_set(canister_id: PrincipalId, num_confirmations: u32) -> Vec<UTXO>
    The function returns the UTXO set corresponding to the given canister_id, where num_confirmations specifies the minimum number of confirmations the UTXO must have. If the number of confirmations is k, then the transaction has k-1 successor Bitcoin blocks.
  • put_transaction(transaction: BtcTransaction) -> BtcSystemResponse
    Requests to submit the given transaction to the Bitcoin network. The response indicates whether the BTC system component has received the transaction, which will then be transmitted to the Bitcoin network asynchronously.

We plan to further provide a library that provides the following convenience functions to developers:

  • get_balance(num_confirmations) -> BtcBalance
    The function returns the Bitcoin balance of the canister for the given number of confirmations.
  • send_bitcoin(amount, recipient) -> BtcSystemResponse
    The function sends the specified Bitcoin amount to the provided recipient address.

In the Networking layer, we implement multiple components required for this feature. Notably, the Bitcoin Adapter implements the Bitcoin-specific functionality in this layer: It connects to the Bitcoin network and maintains a recent view of the Bitcoin network and provides blocks to the Consensus layer on request. Adapters perform a first validation of Bitcoin blocks to prevent dishonest Bitcoin nodes from spamming the BTC system component.

The BTC system component receives Bitcoin blocks that are provided by the Bitcoin Adapter at the Networking layer via Consensus and Message Routing. A protocol between the Bitcoin Adapter and the BTC system component enables the Bitcoin Adapter to decide which block to provide next. The BTC system component further makes outgoing Bitcoin transactions available at the Networking layer, where they are transmitted to the connected Bitcoin nodes.

894×748 109 KB

High-level architecture

Alternative Designs

The proposed design has emerged from an evaluation of multiple possible designs and has been found to be the most suitable design for the Internet Computer in terms of architectural cleanliness, decentralization, and scalability.

An alternative design that was considered is the introduction of an oracle canister, which is a regular canister that offers the functionality of serving UTXO sets to canisters and accepting Bitcoin transactions. This design has several shortcomings. First, relays would be required to send Bitcoin blocks to this canister, which would entail that trust assumptions related to these relays must be introduced. This design is not in line with the goal of having a direct integration. Additionally, the design suffers from scalability limitations as all Bitcoin smart contract canisters would be interacting with the oracle canister.

Another design we investigated was to introduce an oracle canister on all subnets where Bitcoin functionality is made available. This design would require these canisters to be “special” in multiple ways: They would have to run without consuming cycles and be instantiated when the subnet starts up. There would be numerous additional technical challenges, for example with respect to routing, which led us to abandon the design.

Roadmap

The feature affects all four layers of the IC protocol stack and requires engineering work by all affected teams. Most engineering effort is expected in the Networking layer and the Execution layer as all the Bitcoin-related functionality is implemented in those layers. The efforts for the integration with Consensus and Message Routing are comparably small.

The implementation work will be carried out on the different layers in parallel as much as possible. While there is no detailed timeline for the development effort, the goal is to have all pieces implemented and tested by the end of 2021.

Naturally, there is a strong dependency on the threshold ECDSA feature in that it is a hard prerequisite for the Bitcoin integration.

It is important to mention the crucial role of quality assurance for both the Bitcoin integration feature and the Threshold ECDSA feature for the reason that once value in the form of Bitcoin has been transferred to canisters, the feature deployment cannot be reasonably rolled back any more.

18 Likes
27

Can I think of the objective in non-technical terms as:

“Each Canister has a Bitcoin wallet on the BTC chain, just like any human would? This way, a given Canister can use Motoko to execute logic that determines when it should send Bitcoin to a native BTC wallet,etc…Just like a person that had Bitcoin wallet was making verbal agreements with another BTC user as to under what conditions BTC would be sent back and forth between the two”

?

Is this accurate / the difference between what DFINITY is doing and having “wrappedBTC” or what the other solutions offer?

2 Likes
28

– I don’t think what I’m thinking about this is quite right, but maybe it’s a step in direction of what’s going on.

2 Likes
29

Would Lightning also be supported with this Bitcoin integration.

30

Maybe also have a look at Tangem, which can control btc with their cold card & app.

1 Like
31

Actually, your interpretion is pretty accurate. :slight_smile:
Indeed, a canister’s Bitcoin funds are reflected on the Bitcoin blockchain, and it can implement any logic that dictates when it sends Bitcoin and how much. The recipient may be a regular Bitcoin user — or another canister!

1 Like
32

So it looks like each replica has an instance of the Bitcoin Adapter? Does that mean each replica is communicating directly with Bitcoin peers over the internet? And each replica (through the adapter) would be validating UTXOs?

So a subnet with 7 replicas would have 7 Bitcoin Adapters, one per replica?

I am trying to assess the decentralization here, and I’m hoping each replica will have to independently obtain and validate UTXOs and match them with the other replicas during consensus.

2 Likes
33

Correct.
And yes, each replica will validate the UTXOs.

2 Likes
34

A couple of questions
1- Given the need to replicate the BTC chainstate into the IC, how will this affect the subnets capacity? Will this mean higher requirements for nodes?
2- How is the second part different from lightning network?

3 Likes
35

Thanks for your questions!
Let me try to answer them:
1 - The subnets will store the UTXOs (roughly 4-10 GB in size depending on data representation) and not hold on to the blocks themselves. So, the Bitcoin integration is not expected to have a significant impact on subnet capacity.
2 - I’m not sure what you mean by “second part” but there are several differences between a lightning channel and a Bitcoin smart contract on the IC. In short, the Lightning network offers bidirectional payment channels for off-ledger transactions. Bitcoin smart contracts on the IC offer arbitrary smart contract logic for Bitcoin that (potentially) any user can interact with.
Smart contracts on the IC further do not have the shortcomings often associated with the Lightning network such as the risk of a fraudulent force close or the risk of establishing “hubs” that constitute endpoints of large number of channels (whose failure may have a detrimental effect on the whole network).

3 Likes
36

Thank you for this. The second part referred to this "(2) Transactions on the Bitcoin network are inherently slow and expensive " on the scope of the project ".

37

Hey folks, looks like questions are still coming in. Do folks prefer we push back the NNS motion to let more questions/iterations come in?

I want to make sure we strike a balance of moving fast but letting people have their say.

3 Likes
38

In case of a subnet subset collusion and a non authorized transaction is signed – can the malicious parties be detected ? if so - can a token economics disadvantage can be added to slash these node providers (maybe staked ICP) ?

3 Likes
39

One last question: are there dApps already just waiting for this integration? If yes, it would have been great to ask and see how precisely they’d want to use it. That could help check if a critical point isn’t missing.

2 Likes
40

Bitcoin is a store of value. It’s not building the new decentralized Internet. [$ICP]

1 Like
41

Update: we are on track to submit NNS motion proposal on Wednesday September 15, at 15:00 UTC.

1 Like