This makes a lot more sense and does sound very convenient. Thank you for clarifying!
Here is a concrete use cas:
Say you are aggregating global payment for local merchants in latin america, south east asia etc.
Once payment are collected merchants get disbursed on demand, but you don’t trust local currencies which may be devaluated. Instead you convert in BTC and have a Canister to hold the BTC and merchant disbursement logic.
In fact canisters that holds btc can replace third 3rd parties in cross border transactions. BTC is becoming a great “reserve currency” to a point that more companies (square, tesla) have part of their reserves in btc not at the bank.
Dear community!
The minutes of the community workshop of November 4, 2021 are available now:
Thanks again for the valuable discussions and input!
Having a smart contract hold Bitcoin without reliance on a centralized intermediary does sound like a powerful use case.
I read through the workshop minutes, and it said that we probably still need wrapped Bitcoin because the confirmation time on the Bitcoin network is too long.
A couple questions of clarification:
- Would wrapped BTC on the IC still be decentralized (as opposed to wBTC on Ethereum), provided that the wrapping canister is autonomous?
- How would the wrapping canister work? For example, I purchase wBTC from an IC wrapping canister using ICP, and get the wBTC immediately. In the meantime, the wrapping canister made a call to the Bitcoin network and is waiting for confirmation. What if the call fails? What happens to the wBTC that was already minted and transferred?
Would wrapped BTC on the IC still be decentralized (as opposed to wBTC on Ethereum), provided that the wrapping canister is autonomous?
Of course, the wrapped Bitcoin would still be decentralized in the same way. What we clearly would need, as you mention, is to make the wrapping canister autonomous, e.g., using the upcoming Service Nervous System (SNS), and allow for tokenized governance.
How would the wrapping canister work? For example, I purchase wBTC from an IC wrapping canister using ICP, and get the wBTC immediately. In the meantime, the wrapping canister made a call to the Bitcoin network and is waiting for confirmation. What if the call fails? What happens to the wBTC that was already minted and transferred?
Consider the following way to implement it through a Wrapped Bitcoin canister:
- A user transfers Bitcoin to her assigned address of the Wrapped Bitcoin canister.
- The canister, once it has received the transaction on the Bitcoin network, makes an entry of the received balance for the principal of the user. This is when the wBTC get minted on the IC. They are being kept track on the ledger in the canister.
- The user can now transfer wrapped Bitcoin to other users by instructing the canister to update the ledger accordingly.
- The canister holds a pool of real Bitcoin of the amount of the issued wBTC, so we have 1:1 backing like Ethereum’s Wrapped Bitcoin. That’s like the good old gold standard, but with digital gold.
Coming to the main part of your question on buying wBTC with ICP:
Users can not only obtain wrapped Bitcoin by depositing real Bitcoin, but also, e.g., pay in ICP for wrapped Bitcoin, thus having a completely decentralized and “trustless” ICP/wBTC exchange. When paying for Bitcoin with ICP, the issued wBTC needs to be backed by an available liquidity pool of real BTC in the canister in order to have a 1:1 backing. This is clearly the preferable option.
This wrapped Bitcoin implementation is part of Phase 2 of the Bitcoin integration and either the Foundation or the community will be doing it. Still be be discussed.
Milestone accomplished! Protocol integration between Bitcoin Adapter and BTC System Component
Our engineering teams have successfully accomplished a major milestone this week by having the protocol between the Bitcoin Adapter in the networking layer and the BTC System Component in the execution layer working! That is, the BTC System Component can request blocks from the Adapter and the Adapter matches the request with its prefetched blocks and provides a new Bitcoin block in case of a match. The new block is processed by the System Component.
The block request by the BTC System Component comprises all block hashes in the view the System Component has of the Bitcoin blockchain. The Adapter responds with a Bitcoin block in case it has a block that fits “on top” of a block the System Component has in its local view.
This protocol-level integration has been done with a single Adapter that is connected to the BTC System Component “directly” and not through the IC protocol stack. This means that the core part of the Bitcoin-related functionality is working now in these two main components, but the communication mechanism is not the one we intend to have in the final system.
The next steps will be to tackle the integration into the protocol stack to have the requests and responses integrate with the IC protocol stack. This will also enable the submission of outgoing transactions. Some of the work on the foundation for the next steps, e.g., the extension of the consensus layer, has been done already.
Sounds like a great pilot use case of SNS!
- A user transfers Bitcoin to her assigned address of the Wrapped Bitcoin canister.
Does every user have their own assigned address, or is it just a single Bitcoin address belonging to the Wrapped Bitcoin canister?
I think I’m starting to understand the flow. For example, if a user wants to purchase some ICP using BTC:
- The user calls the Bitcoin network to transfer their BTC to the Wrapped Bitcoin Canister
- The Wrapped Bitcoin Canister listens to transactions on the Bitcoin network, discovers this transaction, and credits the user with some wBTC
- The user calls an Exchange Canister to convert their wBTC to ICP; the Exchange Canister calls both the Wrapped Bitcoin Canister and the ICP Ledger Canister to perform this exchange (needs to be atomic, which may require two-phase commit or saga)
Does that sound right?
Hi @jzxchiang!
Sorry for the late response.
Indeed!
Either approach is possible:
- You can use BIP-32 key derivation to derive a key for each user principal to which the funds are transferred. This makes it trivial to associate the transfer with the principal.
- Every user can transfer to the same address of the canister and (mis)use the Bitcoin opcodes to encode the principal into the transaction.
The first bullet above is exactly right! The second one is slightly different: The Wrapped Bitcoin Canister uses the API of the BTC System Component to know about UTXOs sent to the Bitcoin address of interest. Once a UTXO is received, the Wrapped Bitcoin Canister issues wBTC by making an according entry in its ledger. With this you already have wBTC on the IC with transactions that have ~2 second finality.
The exchange canister is the tricky entity here as it is a decentralized exchange (DEX), which would be one application of wBTC. A DEX can be implemented using different technologies, e.g., order book or automated market makers.
Essentially, we require liquidity in the currency pairs the exchange offers (here only ICP/BTC) in order to fulfill orders for the pair and have a liquid market. Liquidity can be provided, e.g., through an Automated Market Maker (AMM) approach. Providing the liquidity would happen through the regular means for the respective token: For ICP, it is bought via some channel, e.g., using USD or EUR, and then transferred to the Exchange Canister. wBTC is provided as outlined in the first 2 bullets and then transferring it to the Exchange Canister.
Thanks for the explanation. It makes sense.
Essentially, we require liquidity in the currency pairs the exchange offers (here only ICP/BTC) in order to fulfill orders for the pair and have a liquid market.
When you mean “we” do you mean DFINITY is planning on implementing a DEX, or that in general DEXs should have liquidity?
We don’t have a DEX on the roadmap so far as far as my knowledge goes. People in the community are interested to build one.
I would also like an update on this topic,
when will it commence and when will it be achieved, as this is the most exciting event. “integration with BTC”
Thank you
Update:
As discussed in the Nov 4 workshop and appreciated by many of its participants, we intend to release a “Developer Preview” of the Bitcoin feature without threshold ECDSA support so that people can start implementing canisters against its interface (and have them ready when the feature becomes generally available ). Details are being discussed at the moment on how to best do so without generating extra efforts yet supporting our developer community as best as possible.
This feature will released on next month?I can’t wait to see it. thanks
We are also excited about this feature!
As @dieter.sommer said above, we won’t be able to release the full feature next month because the threshold ECDSA feature is not ready yet.
The current goal is to deliver a “developer preview” so that developers can start working with it and provide feedback.
The release date for this preview is not set yet but we will probably release it in December or January (to start the new year with a bang! ).
Besides the update on the timeline by Thomas (@thlo) above, let me give a brief update on what we are working currently.
One of our current foci is working out an approach to testing, both for our internal development and for folks who develop smart contract canisters.
- For our internal testing we are evaluating the use of bitcoind in regtest mode to simulate our own Bitcoin network. Another possible option is writing a mock that is likely easier to integrate with our development pipeline and testing infrastructure. The goal here is to have an approach that allows us to do most of the testing of our implementation without connecting to either the Bitcoin mainnet or testnet as part of our system and production tests that test the system as a whole.
- For developers of smart contract canisters we intend, as already outlined, to provide an integration with the Bitcoin testnet. The likely solution on how this is done is to run another Bitcoin Adapter for the testnet integration and have it provide the blocks related to the testnet. The BTC System Component would keep track of both mainnet and testnet UTXO sets and canisters could choose which network they would like to work with for the API calls. This is currently in the design phase and seems to be something everybody interested in the feature wants us to build. However, it does require some extra work, e.g., running another adapter on each replica and tweaking the algorithm for assessing changes to the hashing difficulty for blocks as the latter has a special case on the testnet to account for the heavily fluctuating hashrate there.
Another testing mechanism we are thinking about is to allow for bitcoind in regtest mode to be used
in local testing before deploying the code to the IC mainnet. Here we are working on the precise way of integration with the dfx toolchain with the goal of finding the best tradeoff between implementation effort and convenience of use of the resulting solution.
The other focus is the integration of the code related to the BTC System Component and the Bitcoin Adapter with the IC protocol stack. This has been shortcut so far and still needs to be done before anything, even a developer preview, can be shipped.
I would recommend if it’s too much extra work (and potentially a security/scalability issue to add the testnet into the IC) then just skip it and get the spec for the main Bitcoin adapter out, sure it’s a bit expensive to test but there’s workarounds, and a well funded grants program .
The IDL is really the main thing devs need to start developing apps with the functionality mocked out prior to threshold ECDSA signatures. So rather than the testnet adapter, I think integration with the IC protocol stack should be Dfinity’s top priority right now.
great to hear that. Hopefully, the full feature will released in January.
The full feature requires threshold ECDSA to be finalized. January will be tight for this, so we will likely see a developer preview in late December or January so people can already start building smart contracts using the Bitcoin functionality. The full release is expected later in Q1/2022.
You are definitely thinking into the right direction! We are currently evaluating what it takes to integrate with the testnet and do it if it’s a reasonable effort. Efforts spent on testing support for customers pay off in the long run in my experience. If it’s too much, we’ll need to see whether we launch a developer preview without it and let people play on Bitcoin mainnet.
The IDL is really the main thing devs need to start developing apps with the functionality mocked out prior to threshold ECDSA signatures. So rather than the testnet adapter, I think integration with the IC protocol stack should be Dfinity’s top priority right now.
The goal is to release the developer preview with the final or very-close-to-final interface so that people can build on it. The integration with the protocol stack to reach this goal has very high priority. I guess that’s what you are mainly interested here, right?
Update
We have thought again what the quickest path is to bring the Bitcoin feature to our community so that smart contract canisters can be implemented against its API. The outcome was that our immediate focus should be on releasing the Bitcoin feature as part of the local dfx development environment in January. The local replica will only connect to a locally-running bitcoind instead of the Bitcoin mainnet or testnet. According to current thinking we release it as a beta version of dfx that contains everything the latest dfx version contains as well as the Bitcoin feature.
This setup will allow community members to start implementing their smart contracts using Bitcoin against the IC Bitcoin API. We think this is the fastest path forward to bring something to our valued community so you can start working with it. Clearly, threshold ECDSA will not be available and be replaced by either our mock API or just an ECDSA library running in the canister. This can easily be swapped out with the real threshold ECDSA API once it is available.
The biggest remaining chunk of work to obtain this MVP is the IC stack integration on which we are focussing right now. This is cutting across the whole IC stack and has a couple of remaining issues open. There’s also further small work items still to be done, which are not interesting enough to talk about them here. We think it is realistic to get all of this done in Januray and ship this MVP in late January, unless we hit some unexpected roadblocks.
This approach spares us lots of effort we would need to do for an IC mainnet launch of the feature, thus we can launch it earlier than we would be able to with the feature running on mainnet. This will be the next step to be worked on, of course.
Besides the above, we have made quite good progress in terms of the testing plan and figuring our how to do test the feature itself reasonable and provide something canisters authors can use for their own tests. More about this in another post.
We are interested in what you think about this modified fast-path approach to a first MVP release of the feature.