These are excellent questions, let me try to answer them.
The Bitcoin API will provide means for querying the UTXO set for specific addresses and for submitting transactions. Then there will be the threshold ECDSA API with methods for obtaining the canister’s public key and signing.
That is, there is indeed some processing to be performed by the canister (e.g., through a library).
We want to offer a library for both Rust and Motoko. Rust is easier as we can build upon a large body of open source libraries. Motoko is more challenging as we need to implement quite some huge chunks of logic ourselves. For this reason we have been thinking of asking the community for help with the Motoko library. That has been on my plate for some time now and your question is an excellent trigger for this.
Some of the larger items we need for the library are the following:
SHA-512: There is a SHA256 implementation that can be used as a basis, this should be quick for someone who knows this well
RIPEMD-160 (for address computation)
Elliptic curve scalar multiplication on the secp256k1 curve (for BIP-32 key derivation)
Bitcoin address derivation
BIP-32 unhardened derivation function
Offering high-level API based on the system APIs
Some of those items are required for computing Bitcoin addresses from public keys and for BIP-32 key derivation. The main problem is that Motoko currently has no FFI to reuse those things from implementations in different languages.
The question now is whether anybody here on this subforum would be interested in helping with those items towards obtaining a Motoko library. If you are interested, please just post here. We would be very happy to work with you on this and provide all the information required to get this done.
Naive question: would implementing a FFI for Motoko be more or less work than individually implementing all of these libraries? I would assume that Motoko compiling down to wasm makes implementing FFI a little bit easier.
I ask because while some of these libraries are more generally useful (e.g. SHA-512), I don’t know if most of them will ever be needed by most application developers.
It is relatively straight forward to embed extra libraries (C or Rust) in the RTS for all canisters. We do that already for bignum arithmetic, for example. This is a shortcut, but it doesn’t scale really, because the set of libraries would still be fixed by the compiler.
Allowing library author to include such code is a hard problem that we shied away from so far: what’s the syntax? How do the type systems interact? How unsafe do we want this to be? How to solve the engineering issues of multi-language builds?
Also it seems that to achieve some of the goals we’d have to wait for newer Wasm features (multi-memory) to land. Given that we still don’t even have simple extensions like multi-value on the IC, this puts this likely into the far future.
Joachim, thanks for the detailed response on this subject. Indeed, we will not see FFI for Motoko any time soon for those reasons. This is somewhat a challenge when it comes to features such as Bitcoin which require a breadth of functionality available for Motoko – we will need to write those functions from scratch. On the positive side, this will help provide a richer library ecosystem for Motoko which we would want anyway in the future.
Interesting thoughts! We have thought about further integrations as well as part of the motion proposal on “General Integration” (Long Term R&D: General Integration (Proposal) - #9 by dieter.sommer) as this is important to bring other cryptocurrencies into the IC for use cases such as decentralized exchanges. The question is, how exactly to bring those cryptocurrencies over. There are multiple ways of doing so, and we should discuss what the community feels should be the way to go:
Bridging ERC-20 coins that already exist in Ethereum: weak trust model as we rely on bridges, but readily available soon (e.g., through the Terabethia bridge)
Bridging individual coins: trust assumptions of a bridge; can be done by the community
Relay-based integration: Integrating a cryptocurrency via a relay-based integration, where reliance on the externally-operated relay is mainly for availability. Using threshold ECDSA ensures a still rather strong trust model as no party holds the signing key for transferring cryptocurrency coins; this would not require extensions to the IC protocol stack and could thus be done by the community, based on a blueprint and maybe reference implementation by the Foundation
Direct integration: integration a la Bitcoin; strongest possible trust model; can only be done by the Foundation; this would only be feasible in case we can reuse the Bitcoin implementation more or less completely and parameterize it for each currency and enable it on given subnets (does anyone here have experience how similar / different the currencies interesting to us are to Bitcoin)
The above is early thinking, but can be a trigger for some broader discussions about what people expect to have.
We are progressing well towards our goal of a Developer Preview at the end of January. The plan is to release the Bitcoin functionality first as part of the Canister SDK (dfx environment). We are currently working on the integration of the code with the IC stack, where much of the code is available already. The Canister SDK will likely be shipped in a beta version with Bitcoin support enabled.
We want to provide, as part of the release, smart contract developers a reasonable means of testing their smart contracts. We settled on providing only support for the locally-running bitcoind initially, which gives our users a flexible means of testing their code during initial development. The Bitcoin IC mainnet release later in Q1 / 2022 will allow for integration with the Bitcoin testnet and mainnet to allow for further testing of smart contracts before a production release.
We have a direct integration of the IC with Ethereum on our roadmap. This would allow for bringing the ERC-20 tokens of Ethereum into the Internet Computer. However, the ERC-20 tokens on Ethereum which are wrapped tokens of Bitcoin-like cryptocurrencies are all bridged to Ethereum, i.e., require the additional trust assumptions of the bridge. A native integration would be able to go without those additional trust assumptions, i.e., be much more secure. Also, transferring ERC-20 tokens from Ethereum to the IC using the direct integration would incur Ethereum gas costs, which would be avoided with a direct integration of those other cryptocurrencies.
Hey Timo, I’m hoping the foundation could use lightning to make it cheap and fast to move BTC to the IC. Some may not want to wait a long time for BTC confirmations, especially if lightning grows in popularity; indeed waiting an hour may not be ideal for certain DeFi applications. Say you want to move BTC into the IC to partake in a long or short position, and need to make the trade near real-time.
I see. So you want a lightning channel to be established between a user and a canister on the IC. Or, alternatively, between one of the big lightning nodes that offer routing and a canister and then the user can indirectly route Btc to the canister.
First of all I would love to see this implemented just because it is cool. But we also have to think if it really gives you the benefits that you think it does. The user already has to have the Btc locked in the lightning channel in advance before the need for a real-time trade occurs. Then the user might just as well lock the Btc in the canister-DEX directly. With centralized exchanges you want to take funds off the exchange as quick as possible to reduce risk but with a DEX in a canister the situation is different. So the need for a lightning channel may be reduced.
With lightning in general the problem is always the other direction, taking funds out, because the exchange cannot keep channels with all its users that are all funded on the exchange side.
Technically I think there are still some open question if this can really be done in both direction. There is some problem with the way that HTLCs work. The IC can do threshold signing but cannot create hashed secrets in a distributed way that are later to be revealed. This has to be investigated in detail. Maybe there are future lightning version that use a different hash function who’s computation can be distributed. Or there might be some hybrid solution that runs almost but not entirely on the IC. That’s TBD.
Our engineering efforts are now fully focussed on the end-of-January release of the Developer Preview. We are on track to realistically ship this preview of the feature by the end of the month. This will allow users to implement canisters against the API that will be (very close to) final.
The following points regarding the API are currently discussed:
Should we provide a separate convenience API for getting the balance for a BTC address? This would mean that users will not need to go through the library, but can directly call this method and receive the balance.
Should we implement pagination already now for the get_UTXOs method? This will not be important for the large majority of use cases, but addresses with huge amounts of UTXOs might lead to the get_UTXOs response hitting the technical limits of multiple MBs. Any opinions on the relevance of this? Requirement or rather a theoretical issue? Are there any Bitcoin addresses where the corresponding UTXO set would be so huge that it would hit a multi-MB limit?
Should we implement pagination already now for the get_UTXOs method?
My very limited personal experience tells me that pagination is important and should be implemented earlier rather than later, since it could affect the choice of data structures as well as other implementation details.
Is Dom talking about 2-second finality on ETH Tx w/ the integration? did I misunderstand him? the Tx throughput is still subject to the ETH’s native limitations, isn’t it? Would this be the same for BTC; still subject to native limitations?
First of all, @memetics, welcome to the Developer Forum!
Let me clarify the aspect of transaction finality: Every transaction for Bitcoin or Ethereum that happens on the Bitcoin or Ethereum networks has the finality and cost of those networks, of course. No one can change that with any form of integration. But, you can transfer BTC or ETH over to the IC once with the native integration, then wrap it on the IC, and use the wrapped BTC or ETH token on the IC with the 2-second transaction finality.
Thus, most BTC and ETH transactions could happen on such wrapped tokens with low finality time and low transaction cost. Only the initial transfer of BTC and ETH into the IC and a settlement transfer back out need to happen on the BTC and ETH blockchains with their respective finality and cost.
Does this answer your question?