Direct Integration with Bitcoin

First of all, @Chowski, welcome to the Developer Forum!

Let’s put the odds on your side by assuming that you meant that your canister is responsible for people to broadcast their possibly lost transaction (being defined as you did, that is the address doesn’t exist or doesn’t accept bitcoins). Even in this case if you consider the general case that is Bitcoin, the private key associated to a Bitcoin address is generated off-chain. This means that if someone tells you to pay to address X and you declare to your smart contract that you want to pay X, then if it’s the first time this address X appears in the Bitcoin blockchain, then you can’t know if your interlocutor has the private key associated to X or sent you an incorrect address (and so he doesn’t have the private key associated to X).

We could think that for being an address Y that sending to doesn’t result in a possibly lost transaction it requires Y to appear in the Bitcoin blockchain and to already have spent at least one UTXO. So in addition to require an initialization phase to prove that at a given time someone was holding the associated private key to this Bitcoin address Y, it doesn’t guarantee that after this moment in time the person who was holding the private key associated to Y still holds it (as he may have lost it).

So as far as I know it’s not a perfect solution anyway.

6 Likes

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. :slight_smile:

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 :grinning: . 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