Direct Integration with Bitcoin

Updated the main description and people involved

I will let the folks working on this answer. I’ve pinged them.

Thanks, Jordan!

1 Like

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!


Thanks for the explanation!

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.


I suppose the account that a canister controls will simply be required to have enough ETH or BTC to perform whatever transaction.

Yes, canisters can pay for their own transactions.

It would be pretty neat if somehow Bitcoin or Ethereum transaction fees could be paid for with cycles.

I agree! Somebody should build such a service. :wink:


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.

1 Like

people on this thread will find this relevant:


Hi, will it be easy to add other blockchain derived from Bitcoin like Litecoin or Bitcoin Cash and will you do it quickly ?


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.


@THLO Just to add to passio’s great question, and I mean this 100% seriously, would that also include Dogecoin given it is a Litecoin derivative?

I’m just saying it’s actually bigger than Litcoin and Bitcoin Cash and has bigger name recognition than all other derivatives combined…

@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.


The day ETH integration gets implemented I will actively campaign for Dogecoin integration you heard it here first.

1 Like

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.

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!

1 Like

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

1 Like