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.

2 Likes

How soon will the official version be released?

As soon as it’s finished.

4 Likes

I’d rather hear this than hear another deadline and watch it pass.

4 Likes