As Islam already mentioned, there are a few limited use cases for the Bitcoin feature without t-ECDSA being available, but those would not be the reason to provide Bitcoin early without t-ECDSA.
The main point of making Bitcoin available in some form to developers before t-ECDSA is available would be to allow folks to already start building their Bitcoin-enabled smart contract canisters early on and have them (almost) ready when we finally launch the Bitcoin feature with t-ECDSA integration. t-ECDSA could be mocked during the development and replaced finally with the real functionality, which is essentially swapping out one mocked method call with the real t-ECDSA signing system call. That is, the main motivation for doing this āpre-releaseā would be to limit the implications on the Bitcoin integration of t-ECDSA slipping into Q1 of next year.
Dumb question, but from a dapp developer POV, Iām curious why access to Bitcoin would be useful.
I can totally see why an Ethereum integration would be usefulā¦ you could create ERC-20 tokens, access DeFi liquidity, etc. Basically, IC would function as a L2 rollup.
But when it comes to Bitcoin use cases, Iām in the dark.
Let me give you some ideas of what you can do once we have Bitcoin integration up and running. In essence, it will allow you to deploy any kind of smart contracts that use Bitcoin much like people do these days on Ethereum with Wrapped Bitcoin (~14 B USD). Just with the difference that the IC is highly scalable, fast, and cheap in terms of cycles / gas cost. Already this alone opens a wide range of application cases.
The main point here is that we can make use of the liquidity on the Bitcoin network for smart contracts on the Internet Computer, without involving any intermediary such as a bridge. The IC is, due to its properties, the most suitable platform for running smart contracts with strong decentralization and at a low cost.
Those kinds of traditional smart contracts using some form of wrapped Bitcoin is not all you can do. Every canister can be a decentralized Bitcoin wallet. That is, you neither need to manage a private key for it yourself, nor do you need to trust any single party for doing this for you. This is a very powerful property enabled by threshold ECDSA signatures on a decentralized platform.
Thinking this further, you can blend in Bitcoin use cases with any kind of application. Or you could realize as simple use cases as paying for cycles of canisters with bitcoin. Or, for example, when decentralizing your dApp using the upcoming SNS (Service Nervous System), you could accept Bitcoin as currency for divesting the governance tokens for your dApp.
Can you expand on this? Are you referring to a secondary market for cycles where someone swaps BTC for XTC or WTC (already converted from ICP) or are you saying that Dfinity sees a future where BTC can be converted to cycles? As someone who has invested in ICP Iād be very concerned about cycles being minted using another token.
Can you expand on this? Are you referring to a secondary market for cycles where someone swaps BTC for XTC or WTC (already converted from ICP) or are you saying that Dfinity sees a future where BTC can be converted to cycles? As someone who has invested in ICP Iād be very concerned about cycles being minted using another token.
Itās the further, that is, the secondary market for cycles. This is an early idea on a potential use case that may be convenient for some, thatās why it has been mentioned above. I would see this in a way that the community can build a canister that allows for exchanging BTC to cycles via ICP. So the canister owner buys ICP and converts them to cycles using the usual mechanisms for this and then sells cycles for BTC. Minting cycles using other tokens than ICP is not envisioned.
That functionality would be convenient when you already own Bitcoin. So you donāt need to sell them to buy ICP and then convert them to cycles, but can go the direct route from Bitcoin to cycles.
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.
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.
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)
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.
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?
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ā
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.
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.
