BTC Testnet < > ICP Integration: the testnet is live 🎉

Developers
1

Dear Internet Computer community!

Since the original Bitcoin Integration dev forum post in July 2021, the team has been down in the trenches with their sleeves rolled up, creating an integration between two networks without untrusted bridges.

It brings us great joy to announce that after a year of hard work (designing, building, testing, redesigning, rebuilding, retesting…), the BTC testnet < > ICP integration is online and ready for developers to try out and start building. As this beta version will have the same API, developers can pre-build canister smart contracts using Bitcoin in preparation for GA.

About the experimental BTC testnet integration:

  • Functionally complete implementation
  • API for Bitcoin testnet Integration available on IC mainnet for public consumption
  • Threshold ECDSA deployment with a test key, which will be deleted once available on IC mainnet for public consumption
  • Development and pre-production testing of canister smart contracts using Bitcoin; same API as the GA release will have
  • Bitcoin testnet will remain available even after GA

*Note that this integration is experimental, meaning that we strongly discourage attaching any real-world value to this integration.

Documentation:

Reminder: The Why

As a year’s work closes, it is worth going over the intent of the project.

How does this help IC developers?

BTC is the world’s largest, decentralized asset pool and payment network. By making direct integration possible, IC developers can create smart contracts that can tap into a lot of liquidity (liquidity is necessary “oxygen” for Defi), which, in turn, will increase their possibilities for traction and impact. In short, access to the BTC network broadens the opportunities for IC defi entrepreneurs.

How does the integration help Web3 (ICP or BTC) users?

The basic version is that this integration is a fully decentralized approach. This contrasts to the traditional method of wrapping tokens where there needs to be trust in some centralized parties as the custodians. Native integration protects the token assets of Web3 smart contract users. One may even argue that it will help BTC users (of whom there are many) more than IC users as this integration provides the first truly safe way to have smart contracts (no unsafe BTC bridges).

Give it a try and let us know what you think!

39 Likes
2

Hey! Amazing work on this. It’s awesome we can derive identities to make cross chain calls!

I am working on a bitcoin integration, but for security/verification purposes, we need to ensure at least 1 block has progressed for certain future actions. Currently, with the provided apis, there is no way to get the current block height (from what I can see).

As a hack/workaround, we could reserve an address and send a “seed” transaction, grabbing that UTXO and checking if it’s confirmations have incremented, but this is complicated for such a simple thing as to checking the block height or ensuring the chain has progressed since the last interaction

So i propose adding a system api call, bitcoin_block_height, which would return the current block height the subnet’s bitcoin adapter is synced to.

4 Likes
3

Hey @oss! I think you can technically get the height, but not very easily. As part of a get_utxos call, you receive a record containing tip_height and tip_block_hash, so I think that gives the info you’re looking for. We’ll consider your feedback for adding a separate API, thanks for bringing it up!

2 Likes
4

@oss Thanks for your feedback. As Manu mentioned, there is currently a way to get the tip hash/height via the get_utxos, but it’s admittedly hacky.

I think it would make sense to add a metrics endpoint to the Bitcoin API, which can include the tip height and hash as well as anything else we think would be useful. I’ve added it to our team’s backlog to spec it out.

3 Likes