How to use BTC on IC? Chain Key Bitcoin Ledger on the Internet Computer
Presented by Mario Pastorelli & Thomas Locher, text compiled by ICPL Research.
This conversation discusses the upcoming vote to build a bitcoin ledger on the internet computer which will leverage chain key technology and bitcoin integration functionality to offer fast and cheap bitcoin transactions. Unlike standard wrapped bitcoin solutions, the proposed architecture does not depend on any third part, making it more secure.
Background & Motivation
Bitcoin Integration
The main idea is to enable canisters to hold bitcoin and also figure out what their current balances are. For that, IC needs to tightly integrate with the bitcoin network itself. We need to process every block of transactions on the bitcoin network to enable canisters to determine their balances and also their set of unspent transaction outputs, which are required then to spend bitcoin. If they want to spend bitcoin, we also need the opposite direction to have canisters submit bitcoin transactions we’ll have, which have to be pushed out again to the bitcoin network.
Bitcoin Integration API
Diving a bit deeper into, essentially the API that is provided as part of this feature, this is the bare minimum at the top. So we need to be able to get the unspent transaction outputs or UTXOs. And we also provide a function to simply get the balance, which is the sum over all the funds in UTXOs of a certain bitcoin address. And then as I mentioned, we need to be able to also send the transaction out to transfer bitcoin again. That is essentially the base of our API and there are some additional APIs already under discussion. They might be added soon. One is to deal with the problem that we need to add fees and we need to figure out what appropriate fees are. So we’ll add a function to get current fees based on what the fees were in recent blocks. What is currently under discussion is the functionality to get a block header for a certain height or a certain hash because we do keep the block headers around but not the blocks. This might be a very interesting function later on when we have the HTTP call functionality in place. So assuming that canisters pull in data from the web maybe even a full bitcoin block, if we have this functionality here, this would enable the canister then to verify that the block is correct by comparing the hash to the hash stored in the block header.
Shortcomings:
Overall, this is a very powerful integration but there are still some shortcomings. The first point here is, one thing that gets asked quite often also in the forum, “will this actually make things cheaper”, “will it make it also faster”? No, because everything still happens on the bitcoin blockchain, and so this aspect does not change at all. The second point is, dealing with all those bitcoin-specific things like UTXOs and so on is quite tedious for developers. It’s also quite error-prone. It’s not so easy and takes a bit of effort to get this right.
Wrapping Bitcoin
One approach that people take when they want to make bitcoin faster or add some sort of smart contract capability to bitcoin is to wrap bitcoin. Here is a very high-level overview of what that essentially means.
We have a part that issues a wrapped bitcoin token. Whenever we send bitcoin to that part, it will return this wrapped bitcoin and as part of that action, create this new token on a different blockchain and the inverse operation exists as well. So we can get bitcoin back out, burning this wrapped token on this other blockchain. The advantage here is that it can be more efficient if you run it on a more efficient blockchain. So this is a solution that you see quite often in the industry right now. A big issue here is that we have this additional part, which might be a centralized part or decentralized. But either way, this is another part that you need to trust. You need to trust the part to always swap the two coins. This also makes the whole flow of maintaining, burning, and so on, more complicated. It technically poses an additional hurdle.
Bitcoin Ledger Based on Chain Key (ckBTC)
On the right side is still the bitcoin integration part. We have replica functionality that talks to the bitcoin network, and the new component is nowhere in the middle. We are introducing a new chain key bitcoin ledger or ckBTC. A user can transfer bitcoin to this ledger directly because as mentioned before, canisters can hold bitcoin and the user can also request bitcoin back, buring its current balance of ckBTC. There is no third part involved here, which makes the whole flow much simpler as I mentioned before. Once we have this token in our ledger, we can transfer it at the speed of the internet computer and also keep costs very low.
There is a discussion about this going on in the forum the link is:
https://forum.dfinity.org/t/feedback-wanted-wrapped-bitcoin-ledger-on-the-internet-computer/10681
Technical Details
Converting BTC to ckBTC:
First of all, from a technical perspective. the ckBTC ledger is going to be two canisters. There will be a ledger on one side and then a separate canister which is the minter, the minty account of the ledger. I am going to focus on the minter. For security and practical reasons, the ledger is any ledger that supports account balance, transferring, and rigging the blocks. The minter has two functionalities. It allows you to convert bitcoins into ckBTCs and vice versa. So we’re going to first see, how we convert bitcoins into ckBTCs and then the opposite direction. As you can see here, we have a sequence diagram. On the left we have the user, then we have the bitcoin network, bitcoin canister, and then we have the Minter and the ledger.
The first part is the user that asks the minter for a bitcoin address. This is an address under the control of the minter, and the minter will reply with the address where the user can submit the bitcoins to convert. The next step is the user transferring bitcoins to this address, and then there is a notification code to the minter which is the update balance method right there. Update balance tells the minter to checks for the new UTXOs in the address. So the minter will call to get UTXOs on the bitcoin canister. Filter them by the ones that you’ve never seen, and then transfer an amount of ckBTC into the account of the user. Optionally, the user can define a sub-account, which is an account under the control of the user. At this point, the Minter is okay, and the user can start using ckBTCs.
Converting ckBTC to BTC
Let’s see the other way around, how do you get bitcoins out of the network. The procedure is symmetric to the one that we have just seen, we also here have a withdrawal account id, like an account where the user can put this ckBTC to be converted to bitcoins. For simplicity, I didn’t add the method here of the user calling the minter to get this account. Remember that the account can be any way that will be secretly created like calculated by the user. So let’s say that the user is using a ledger to calculate it and we call it withdrawal account ID. This is again an account ID that is under the control of the minter, and it’s unique for the user.
At the beginning, the user transfers the amount of ckBTC that wants to convert to bitcoin to the ledger, to this withdrawal account ID. After that, the user calls the retrieve bitcoin method of the minter. The minter then burns the ckBTCs and sends a transaction to the bitcoin network, but the bitcoin cut through the bitcoin candidates into the bitcoin network, to send back bitcoins. This part is a bit more complex than what you’re seeing in this slide, we’re going to talk about that next. For now, let’s assume this is what’s going to happen. After that, the meter returns ok to the user. It’s important to notice that at this point, the transaction has been initialized, it has been submitted to the bitcoin network, but it’s not completed yet. So different from the previous slide, the user cannot use bitcoins immediately or potentially could not use
bitcoins immediately, because it takes some time. We provide an APA so that you can check the state of the transaction and see when it gets confirmed.
UTXO Management:
We are going to focus on the UTXOs that are under the control of the minter. There are roughly three sets of UTXOs. The one on the left (the yellow one) is the undiscovered UTXOs. There are UTXOs that are available in the address of the minter but the mintor has not been notified yet of their existence. So you cannot use them. When update balance is called, that’s when the minter finds the new UTXO, so they move from undiscovered to discovered. It’s when the minter means ckBTCs, but also puts the UTXOs in a pool called available UTXOs pool. This is where all the UTXOs that the minter can use in a retrieve bitcoin operation, are available to be used.
After that when a user calls to retrieve bitcoin, some of these available UTXOs get reserved for the request and marked as used UTXOs. One important aspect of the current implementation is that the UTXO can be used only for one request, meaning that once the UTXO has been reserved for a request, no other requests can use it.
Then it’s useful to see the (4) there. In the end, when the outgoing transaction got confirmed effectively, that transaction will have several outputs and one of those outputs will go back into the available UTXO, which is the difference between the sum of UTXOs bank and the amount requested by the user.
Converting ckBTC to BTC
Let’s talk again about converting ckBTC to bitcoins. We saw the high-level approach before, but I would like to go down to details a little bit because if you know how UTXOs work, you need to spend them all. There is a chance that the retrieve bitcoin operation cannot be fulfilled immediately because the minter doesn’t have enough UTXOs. The real approach is the following: when a user calls to retrieve bitcoin, the minter records the request immediately, which we call pending queue. Pending stands for pending request queue.
During the heartbeat of the minter, the minter checks what are the pending requests, checks which UTXO it has available at the moment. And then, for all the requests that it can fulfill, it will submit them to the bitcoin network. This is when the actual transaction is submitted. And all the requests that can be fulfilled will be moved to another queue, an unconfirmed queue. This is the queue of all the outgoing transactions that yet need to be confirmed by the bitcoin network. That’s basically how this will work. One additional thing is that each request can be resubmitted by a user with a higher fee. The fee is removed from the amount requested by the user, but it increases the priority of that request. So you may have multiple transactions going out for the same request. All the transactions of the same request will have to use the same UTXO though.
Q&A
Q: One of the benefits of having a native integration is that it’s much more secure than that of a bridge. If this is so groundbreaking and if it’s so secure, why is it that another chain hasn’t done this before?
Mario: It’s difficult to answer this because we would have to ask other chains why they are not doing it. On our side, I think it’s just better, more secure to do it this way, without a third part involved. It’s also much easier on the IC side.
Thomas: If you take an example like Ethereum, there anybody can run just a node but here what we required is that the replicas actually interact also with the bitcoin blockchain, and exchange messages to sign then to get signatures for outgoing calls, which again have to be relayed. It’s not clear how that would fit at all into a model, like the processing model that Ethereum has. So it would in more ways than one is very challenging to pull off.
Hugo: With respect to other chains like Ethereum, you don’t have deep processing capabilities. That’s part of the whole internet computer meme. And what the internet computer is about is that your smart contracts are now processes that can do more rich interesting things like threshold cryptography. So the simple fact of the matter is, none of the other chains are even able to come close to doing complex things like this. More or fewer EVM chains are just fancy ledgers, like lots of smart contracts are just token databases that allow you to transfer numbers back and forth and not complex computational tasks. It’s not just another blockchain. It’s a completely different paradigm, thinking about computing on blockchain.
Thomas: Coming back to one aspect that I mentioned before that is very important is, threshold ECDSA, which is a very key building block. If you have Ethereum, it’s absolutely unclear how you would try to instantiate that across all the thousands of nodes. So the entire execution model is so different that this whole approach that we’re taking would not work. So they would have to invent something new entirely.
Q: Can a user request multiple bitcoin addresses per user principle?
Mario: The current design is only one because we only want one unique point where we can submit things to pick them up. This keeps the design much simpler to have just one entry point for bitcoin. But if anybody feels this is a limitation in one way or another, we’d be interested to hear about it. We can extend it if there is a good reason.
Q: Will there be any transaction fees that the user must pay to transfer ckBTC?
Mario: Yes, there will be a transaction fee, similar to what we have with the ICP ledger. The main purpose of the fee is to prevent spamming, the creation of pointless transactions going back and forth. It will be cheap but probably in the same order of magnitude as current ICP transactions. Currently, the constant fee that we are proposing is 10 satoshi.
Q: What will be set as the controllers of the minter and ckBTC ledgers?
Mario: It’s probably going to be the root canister. We don’t know yet when we’re going to deploy this, we’re still discussing it. It’s very going to be a system network and probably going to be a root canister that is responsible for updating. These two in the same way we do with the ICP ledger. In short, the NNS will control.
Q: Why isn’t the bitcoin integration not the ckBTC canister built using a standard canister with the outgoing HTTP calls feature?
Mario: In some sense, it’s related because the HTTP call feature will use some sort of an adapter at the networking layer to make these calls to the web. And we essentially have a bitcoin adapter that does the same thing for bitcoin. So the main difference is that this is a bit more integrated into the replica stack. But we have our core component in the execution layer that interacts with this adapter to pull in bitcoin information. So it’s not unrelated at all.
Q: What is the current progress on this? Is there a release date? Is there a roadmap for this?
Mario: The short-term roadmap after this call, the idea is to publish the motion proposal tomorrow, and then we will see if this is actually accepted by the community. If it is, development work will essentially start right away. It’s hard to give it a clear date when this will come out because it depends very much on the bitcoin integration work. So this has to be completed first before we can do proper system testing. So we will definitely come after. Currently, a Q3 is like a target for release.
Q: Could you provide a quick review of the canister architecture of ckBTC, specifically how many unique canisters are in the design and what is the one-sentence brief for each?
Mario: At this point, we have two main canisters, the ledger, and the minter, which are the ones you saw on the slide. The minter account is basically the minter of the ledger and the ledger itself is a standard ledger, so you can do transactions, get your balance with the blocks. Just keep in mind that the ledger itself has sustainable canisters because it’s an ever-growing list of blocks. It needs to spawn archive canisters and that’s dynamic. So there are sub-canisters on the control of the ledger. Apart from that, those are the only two real canisters, then you have the bitcoin /canister.
Q: Each user might want to generate multiple addresses to send their BTC to the ckBTC minter. This I believe is a fundamental privacy best practice for using bitcoin, one unique address per transaction. Do you think this is important?
Mario: Yes I think it’s important. I don’t think we want to have one address per transaction, but it’s exactly something we want to discuss.
Thomas: We don’t have it in the design. But if there’s a good reason, like some privacy concerns, we can definitely revisit that topic and if it doesn’t introduce a big complication, it’s definitely something we can do.
Q: What are the limitations of a canister that the bitcoin integration needed to be built into the replica?
Mario: Yes. It would have been possible to build a canister-based solution, but there would be some technical challenges. For example, if it’s a single canister, then everybody would have to talk to that one canister. We had we quickly kind of transition to a view where every or multitude of subnets would have this functionality and then the question is how do you start routing across multiple canisters that offer the same functionality so that routing questions aren’t pop-up. Then finally we would have to worry about cycles, who will top them up, do they have to pay. If they run on system subnets they don’t need to pay, but then we’re again very limited in the number of subnets we run the functionality on. And if we run it on application subnets, we might want to still have the not-pay cycles, but that is currently not supported. So there are many technical issues this solution has, so we decided it would be kind of cleaner to have this as part of the replica.
Q: Would it be possible to use the BTC ledger to perform a simple transfer between two BTC addresses without going to the minter?
Mario: The minter is only used for maintaining ckBTCs and giving back bitcoin every other call goes through the net to the ledger directly. If you do a transfer, you don’t pass through them. You just send the transaction through the ledger.
Q: What use cases are you both most intrigued to see implemented by (1) the IC ecosystem and (2) the BTC ecosystem?
Mario: Regarding bitcoin integration, that’s our focus. We’re quite excited to see decentralized exchanges coming up and hopefully, we can get them to work with our chain key bitcoin. That’s the first step. But because it’s cheap, we would like to see really fast trading going on, high-frequency trading. Not some millisecond high-frequency trading, but in high-frequency trading for the blockchain world where you can really do tons of transactions at a low cost. That’s something we’ve never seen anywhere and I’m hoping we will see that on the IC.
Commerce and trading are the two use cases that we would like to see. Once we have implemented the fundamental building blocks and deployed everything related to Defi, it’s interesting.
Q: We’ve talked about the security benefits of doing a direct integration, are there any surface areas for attacks for potential hackers or bad actors even with this model?
Mario: The design is almost complete right now, we’re discussing a security team to understand the possible source of attacks. I can tell you if there are any real attacks because most of them have been already fixed or covered during the design process. I hope we can polish and clean it up enough to avoid any potential attack. Still, the idea is that the two canisters will be easy to upgrade in case of an attack.
This work relies heavily on the security of the bitcoin integration feature itself, which relies on the security of the threshold ECDSA. So there’s a heavy focus on making that as secure as possible, we’re just relying on this part. Of course, it is possible for people still to write malicious canister code, when would that steal either your bitcoin or your ckBTC. If that’s the logic of the canister, then there is not much we can do. So people have to be careful where they send their funds to.
Q: How is all the non-wrapped BTC going to be stored? Is it all going to be on one source, i.e minter, or will it be spread out to multiple canisters to spread out risk?
Mario: This relates to how threshold ECDSA works in our system. Essentially we will have one very large subnet that shares a master key from which keys for every canister are derived. In some sense, you might argue that there is a single holder of all the bitcoin in the system. But this is delegated to individual canisters. So their sub-keys can transfer their share of bitcoin around. It’s on the various layers and it’s before you touch the minter canister layer.
Q: How much more difficult is it to do an Ethereum integration versus a bitcoin integration, assuming that the proposals get passed?
Mario: We didn’t study yet even if there was some push. At the moment, we didn’t have the time yet. What I hope will happen is that we will provide a template for future integrations with other tokens. In general, Ethereum is much more complicated. But how hard it will be to integrate depends very much on what the goal is of the integration, whether it’s just to provide some means to get all the blocks in, or whether we want to do actual execution of their smart contracts as well. This is not decided, so we can’t say for sure at this stage. But this will also be a discussion with the community to figure out what exactly we want out of this integration.
