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?
wrapped tokens with low finality time and low transaction cost.
The way I understand it these wrapped tokens should still be be safer than the alternatives on other chains, cause nobody knows the private keys, so they’d work more like renBTC rather than WBTC, If thats the case the only risks of using the wrapped version rather than the native one are potential vulnerabilities in the canisters that handle the tokens or the remote possibility the NNS decides to shut down the canister. Is that correct?
That’s my understanding. This is in stark contrast to WBTC on Ethereum, where the private keys needed to mint new tokens are held by a centralized custodian, i.e. BitGo.
The types of interesting, intra-chain DeFi applications that were made possible by Ethereum will now be possible cross-chain. Pretty exciting stuff.
@trannghia:
The direct integration does not require any intermediaries, such as trusted bridges, which would lock up the received Bitcoin and mint the wrapped tokens. In the direct integration, smart contracts directly can hold Bitcoin as they can have their own threshold ECDSA private key that is secret shared among the replicas of a large subnet. So, the direct integration features a much stronger trust model than a bridge-based solution.
A developer preview that allows people to use the API will be available already by around end of January. The release of the feature on IC mainnet is planned to happen by the end of Q1.
What’s the difference between the Bitcoin smart contracts IC can achieve with the direct integration and the Bitcoin smart contracts Stacks STX provides?
IMHO …When I took a look at Stacks, it appeared to be similiar to about 90% of the crypto space. A bunch of vaporware mumbo jumbo. Perhaps though your research will offset the following criticism…
No scientific paper describing consensus protocol.
No soundness or liveness proof.
All I found was a rather light explanation of the PoX consensus. (Proof of Transfer) . What is the connection to miners? Who knows! Block producers bid for the right to create blocks by transferring bitcoins to another group called stackers. The motivation is STX but it gets convoluted when you dig further. I do like the ‘Hard Fork to Proof of Burn’ scenario. Sounds like film noir.
The Stacks 2.0 native currency is not Bitcoin. There is not even a wrapped-BTC token as far I can tell.
There is a STX token and the developers want folks to lock it for a long period… obviously.
They do use ‘Bitcoin technology’ to secure consensus so they have a Bitcoin blockchain oracle I think.
But I give a thumbs down to their ‘built on Bitcoin’ shtick …
Progress update:
We have made lots of progress towards the Developer Preview release of the Bitcoin integration feature. This release will come out next week and allow people to use the Bitcoin API already now.
Let me briefly summarize below what you get with this preview release:
Scope:
Bringing the (close to final) APIs to our community; this should allow folks who want to use the API to already do so now in their development environment
Main goals
Bring the API to the people so they can play around already now, thereby bridging the gap between the original release date end of 2021 to the new release date end of Q1 2022
Facilitate smart contract development by community members already now
Get community feedback for the API for the final release
The Bitcoin-related logic is almost completely available
Almost zero engineering waste created by the DP release
This release does not use the final architecture for the integration, but does it in the following simplified way (this does not matter for the local environment and the intended goals):
APIs will be exposed as a regular canister (BTC Canister) running locally, not as a system API, for now
bitcoind in regtest mode is used instead of the Bitcoin mainnet or testnet (this makes sense for the lowest-level dev/testing stage anyway)
The IC stack integration is shortcut via ingress messages and queries, the full IC stack integration with consensus is being finalized in parallel and will be released in the Q1 release
Users start the Bitcoin adapter, integration shim, bitcoind, and BTC canister with a script
There’s no threshold ECDSA yet in this release
We will provide small sample dApps in both Rust and Motoko that make use of the interface
The following is not in scope and will not be available in this release. Non-scope:
Threshold ECDSA (in this release, people need to use an ECDSA library in the canister for now to sign transactions)
Bitcoin testnet and Bitcoin mainnet integration
Library to abstract the interface and make it more convenient for the users
