Thank you for your so quick answer, I am impressed and it’s very exciting.
Will the API change? Will we still access the functionality through the management canister?
2 Likes
Just to be clear, this affects the (once virtual, now real) Bitcoin canister and not the wrapped Bitcoin canister (which was always intended to be a real wasm canister), right?
Indeed! Everyone is happy that we can go down this road now.
You are welcome!
This is under discussion and inputs from the community side are welcome. One strong reason to keep the management canister ist that it would allow deterministic load balancing between multiple BTC canisters, all with the same canister id. Of course, a reason to go with a regular canister identifier is simplicity and less replica code, but it does not allow for transparent load balancing. In the latest discussions, we were leaning towards keeping the management canister API to have the additional flexibility.
Exactly!
3 Likes
This load balancing feature (behind a single logical canister ID) seems like a really useful feature for canister developers as well. I wonder if it will ever be exposed as a public API; basically, let users create their own virtual canisters a la the management canister.
4 Likes
How soon will the official version be released？
As soon as it’s finished.
7 Likes
I’d rather hear this than hear another deadline and watch it pass.
6 Likes
Dear community!
Let me give you another update from what is happening in the Bitcoin feature.
In the most recent update further above, we have been announcing the new architecture of most logic of the implementation being moved into a Wasm canister. Now we are already starting to harvest the fruits of this move, namely being able to iterate much faster on the performance improvements we have been working on.
The following performance optimizations have been implemented recently:
- Fee percentiles for the fee query are being cached now.
- We have a profiling framework that helps with identifying performance bottlenecks and help our engineering speed.
- Transaction ids are cached once computed to avoid to repeatedly perform the same resource-intensive computations.
- Replaying unstable blocks has been optimized dramatically: This operation is required to keep the most recent blocks, e.g., 144 blocks for a day worth of blocks, as unstable blocks not merged with the UTXO set yet. Replaying of all unstable blocks needs to be done whenever someone makes a UTXO query, i.e., it is an essential operation and crucial for performance of a core aspect of the feature, namely, retrieving the UTXO set of a Bitcoin address.
In addition to the above optimizations, we have been starting a Bitcoin Testnet sync on an IC testnet, which has been running successfully so far (unfortunately the testnet was accidentally claimed by someone else and cleared at around block 2.2M of 2.35M blocks, i.e., close to the syncing being finished). Key metrics such as the checkpointing time (2-3s) and finalization rate have been looking very good as well, so far confirming the architectural change we made. The speed at which we can iterate, e.g., for performance improvements, has improved visibly, so the investment in the architectural change will have amortized rather quickly.
And: No new deadline communicated now, it’s done when it’s done. 
43 Likes
Very good progress, and I’m especially excited that it shows the potential of Canister and how to fully exploit this potential. Looking forward to more information on this in the future, including the profiling framework
5 Likes
After the full BTC integration is released, what would it take to enable Lightning support on the IC?
4 Likes
Thanks @dieter.sommer. Understood that no new deadline will be issued, but the old deadline was 2/3 months which put it at October/November. To the extent you believe that timeline will slip I do think its better to let the community know sooner rather than later.
5 Likes
We have been making excellent progress with the Bitcoin canister implementation – the velocity of development has improved quite a bit with the new architecture. We are now working on a mechanism to launch the Bitcoin canister with a UTXO set that can be precomputed off chain to avoid the long bootstrapping times of the canister syncing the complete Bitcoin blockchain on chain. This helps greatly reduce the time it takes to get the canister up and running (ready to serve requests) once the source code has been finalized.
November is still looking to be feasible for the GA release of the Bitcoin feature. As a first step, the current Bitcoin Testnet implementation will be switched over from the replica-based implementation to the new Wasm canister architecture, still remaining on a 13-node subnet. Then, the Bitcoin canister code can finally be removed from the replica. The canister for Bitcoin Mainnet will be launched on a high-replication subnet for better security.
30 Likes
These updates are very helpful, @dieter.sommer . I think of early 2023 as a kind of rebirth of the IC, with a series of major upgrades all coming onstream.
7 Likes
Amazing thanks so much Dieter. The steady communication is really appreciated.
What does this mean for scalability? Is the expected throughput still 1 tps per subnet?
4 Likes
sounds good. I can’t wait to see the release on that time.
Doesn’t change anything if marketing is as it is right now. People sentiment towards Icp is still as bad. I think 1 thing could really change it is to have a famous Twitter/YouTube influencer that really learn about Icp and promote it (of course after all the goodie updates gets rolled out).
4 Likes
I have given up on the marketing side of matters. I mean, these are people who thought Internet Computer was a good name for a blockchain and who thought weird URLs could be a selling point rather than a roadblock 
. The IC is built by techies who don’t know what they don’t know outside of their domain. Still, within their domain they are brilliant, and we must hope that will be enough. The first quarter of 2023 should give us an indication if that is the case.
1 Like
This only magnifies the importance of small developer + retail participation in NNS governance as well as forums like this. Its nice to see such an active ICP community.
2 Likes