The Internet Computer will add smart contracts to Bitcoin through an application of Chain Key cryptography that will directly integrate the networks. Smart contracts on the Internet Computer will be able to hold, send and receive bitcoin, without the need for private keys.
The scope of this feature is the integration of the Internet Computer with the Bitcoin blockchain with the following goals: (1) Making powerful smart contract functionality available for Bitcoin transactions; (2) enabling Bitcoin transactions with fast finality and low transaction cost.
(1) Bitcoin does not support generic smart contract functionality, but only a limited scripting language that supports a small subset of general smart contract semantics. The envisioned smart contract functionality for Bitcoin transactions allows a user to deploy a canister or make use of an existing canister that can receive and transfer Bitcoin and execute arbitrary smart contract logic expressed in a Turing-complete programming language. To this end, canisters must be able to hold Bitcoin balances, which requires a threshold ECDSA protocol. This protocol enables the replicas hosting a canister to share an ECDSA private key and create ECDSA signatures using cryptographic multi-party computation using a secret-shared private key, that is, without any node learning any information about the private key while jointly computing signatures to sign transactions. Smart contracts require access to the state of the Bitcoin blockchain, the so-called chainstate. Thus, we need to replicate the chainstate on the Internet Computer and provide services to canisters implementing smart contracts to query it and thereby receive UTXO-related information. This feature allows any canister to validate and create Bitcoin transactions and implement powerful smart contract logic.
(2) Transactions on the Bitcoin network are inherently slow and expensive. We want to enable fast and low-cost transactions by building ledger functionality on the Internet Computer that allows users to transfer Bitcoin into and out of accounts on this ledger, thereby creating wrapped Bitcoin on the Internet Computer. Users can transfer Bitcoin into their accounts on the ledger and buy and sell Bitcoin with ledger transactions on the Internet Computer with finality in seconds, while incurring only a tiny fraction of the transaction fees when compared to executing the same transaction on the Bitcoin blockchain. Holders of wrapped Bitcoin can settle their accounts any time by having their account balance transferred to their Bitcoin address.
My main question with the Bitcoin and Ethereum integration is how the interaction from Bitcoin/Ethereum → IC happens securely, without a bridge, given that Bitcoin and Ethereum do not have a chain key.
I’m working on the integration and can try to answer your question.
As Dom explained, the IC will pull in blocks and verify that they are correct (i.e., well-formed, correct difficulty, …) and process the transactions after a certain number of confirmations.
Since the IC replicas pull in blocks from the Bitcoin network directly, the security depends on the correct functioning of both the IC and the Bitcoin network (but not on anything else).
In some sense, this still only gives you a “bridge”. The more exciting part is that canisters will be able to have a shared ECDCA key (sharing the key using threshold cryptography, see also here) so that a canister can securely hold Bitcoin (or Ether) itself! The Bitcoin (and Ethereum) state is then mainly used to keep track of the current balance for each canister that holds Bitcoin (and Ether).
Does this answer your question? If you have any follow-up questions, please let us know!
So will each replica run its own Bitcoin and Ethereum node? Will the subnets come to consensus on the Bitcoin and Ethereum blocks? I’m trying to understand if the replicas will all share a Bitcoin or Ethereum node, of if they will be independent.
I’m hoping they’ll each have their own, thus inheriting the security properties of Internet Computer Consensus.
Also, how will base layer Bitcoin and Ethereum transaction fees be paid for? I suppose the account that a canister controls will simply be required to have enough ETH or BTC to perform whatever transaction.
It would be pretty neat if somehow Bitcoin or Ethereum transaction fees could be paid for with cycles.
The current plan is not to run Bitcoin/Ethereum nodes on the replicas. Instead, there will be dedicated adapters on the replicas fetching blocks directly from the Bitcoin/Ethereum P2P networks. But yes, these blocks will go through consensus so that the replicas continue to share the same state and the system retains the desired security properties.
Update: Now that Increased Canister Storage has gone through community-wide voting, this is the next project (1 of multiple concurrently) that will go through a similar open design process and voting.
I will let @THLO answer on how similar it is to use this project for other networks, but I can say that the current plan (which we will put to a Vote for the community) is to do BTC first then ETH.
@diegop is right, the plan is to first do the Bitcoin integration and then the Ethereum integration.
There will be specific code introduced for these blockchains (for example dedicated adapters to connect to the Bitcoin and Ethereum P2P networks). So, the goal is to add support for these two blockchains only.
If these integrations turn out to be a big success and the community asks for the integration of Litecoin, Dogecoin, and other derivatives, we can put this to a vote, of course.
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.
