The day ETH integration gets implemented I will actively campaign for Dogecoin integration you heard it here first.
I was listening to @Manu 's explanation on the podcast this morning and a question occurred to me.
The IC is secure because the subnets can refresh the public key and switch it out for a new key via a zk generation of a key portion. They can do this a bunch so bad actors have limited time to coordinate(I don’t know how often this actually happens…would be great to know).
With BTC and ETH integrating, we need to control addresses and contracts from a specific identity. Once these are generated and on chain, you can’t really swap them out(unless the contract you are interacting with supports it). So will these keys be inherently less secure? If I ask the subnet to generate an address for me, I’m guessing all nodes have a bit of the key. If >2/3 decide I have too much at my address they could collude to take it? And they have infinity amount of time to do this because I can’t change the key on the remote chains?
What if more than 1/3 of the original nodes that generated your key portions go offline permanently? The IC can just add new nodes and generate a new public key…ETH and BTC won’t be able to do this.
I’m probably missing something here, but I think it is worth understanding.
Edit: I’m sure on ETH you could overcome this by always sending requests through a wallet-like contract that has the functionality for swapping out keys…not sure about BTC.
If the canister can control the key surely the canister can every one and again transfer the bitcoin to a new bitcoin address, and derive a new chainkey from it with different actors. I have no idea whether this would be worked into the protocol, but is possible theoretically.
I would agree that that is fairly straightforward for standard bitcoin transactions, but for anything more complex it would be a nightmare. What if that key was used for an n of m multisig account? You’d have to organize everyone to change it. Eth with contracts are event more complicated because there is no way to know today what a programmer may put in a contract tomorrow as an ownership transfer mechanism.
ETH sounds more difficult, agree. Perhaps multisig is not such a big issue on the BTC-side as complex escrow could be implemented IC-side?
Would be great in general to see what the high-level APIs look like.
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!
Hey folks, I updated the main description with the current timeline.
Lol same here. That’s hilarious.
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).
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.
Main authors: Dieter Sommer, @THLO
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.
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:
- Enabling canisters to receive and hold Bitcoin on the Bitcoin network;
- Tracking the UTXO set belonging to canisters and enabling canisters to query their respective UTXO set;
- 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.
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-1successor 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.
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.
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.
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?
– 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.
Would Lightning also be supported with this Bitcoin integration.
Maybe also have a look at Tangem, which can control btc with their cold card & app.
Actually, your interpretion is pretty accurate.
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!
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.
And yes, each replica will validate the UTXOs.
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?
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).
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 ".