This is great news! Amazing work everyone, looking forward to integrating this into Earth Wallet and giving feedback on the APIs 
4 Likes
Awesome, feedback on APIs will always be greatly appreciated! 
5 Likes
We are planning to make the source code of the Bitcoin logic already available as well with the Developer Preview release in the upcoming week!
Feedback is of course also much appreciated for the code.
9 Likes
End-of-week update:
This is (with overwhelming probability) the last end-of-week update before the release of the Developer Preview which is scheduled for next Thursday, February 3rd, 15:00 UTC+1. We are well on track with the implementation, documentation, and open sourcing tasks and are confident that we will be able to stick to the defined release date.
Sneak preview on the API:
For those interested in the API already now, please find the current draft PR here: Adding the Bitcoin candid file and specification by THLO ¡ Pull Request #5 ¡ dfinity/interface-spec ¡ GitHub
This is the API included with the Developer Preview release. It will be subject to your scrutiny so we can all benefit from your experiences with it in the final release.
By the way, for those of you who have not seen this yet, the IC interface specification repository is public now! See: GitHub - dfinity/interface-spec: IC Interface Specification
17 Likes
Wow!
Great Wish to the Team and Dfinity Community 
1 Like
Can we watch the preview?
The Bitcoin integration developer preview is publicly available now
The Bitcoin developer preview has been released to the public, including all associated source code. Please visit Bitcoin integration :: Internet Computer for an overview of the release and links to the code, installation and usage instructions, the API documentation, a Wiki page with technical documentation, and example projects in Rust and Motoko.
With this release we reach an important milestone in the process towards a direct, trustless, integration with the Bitcoin network that will soon start a new era of DeFi! The developer preview enables you to start writing and testing smart contracts that use the Bitcoin API right now.
We hope that many of you will try out the preview release, start working on exciting smart contracts using the Bitcoin integration. We will greatly appreciate feedback on the developer preview, and particularly the API, to improve it further towards the final launch of the feature. We are planning to host a workshop in about a month from now where we would like to invite people interested in contributing to improvements.
Many thanks to @ielashi, @0x5279616e, and @THLO for their tremendous effort in finalizing the implementation of the developer preview, for getting the documentation ready, and even providing small sample projects in both Rust and Motoko in time for this preview release! Many thanks to everybody else who has contributed to the Bitcoin integration feature, particularly @Manu who has provided guidance w.r.t. key engineering questions!
Enjoy the developer preview, we are very much looking forward to your feedback!
The Bitcoin integration team at DFINITY
30 Likes
Hereâs another announcement: We decided to build our own wrapped Bitcoin ledger to further speed up the development of Bitcoin smart contracts on the Internet Computer.
Please post your feedback and questions in this channel!
8 Likes
A couple concerns/questions (I have never actually done Bitcoin development before so please help me through this):
- Is there a way to query from the blockchain an appropriate transaction fee instead of using the hard-coded fee? https://github.com/dfinity/bitcoin-developer-preview/blob/master/examples/rust/src/main.rs#L123
- Can we get rid of the need to cache spent txos? Shouldnât the utxos by definition not contain any spent txos? https://github.com/dfinity/bitcoin-developer-preview/blob/master/examples/rust/src/main.rs#L142
- With the API provided, are we able to deploy bitcoin smart contracts (as in code running on the bitcoin blockchain)?
1 Like
Hey @lastmjs, thanks for the quick feedback and great questions.
Is there a way to query from the blockchain an appropriate transaction fee instead of using the hard-coded fee?
Not at the moment, but it has become more apparent to us that we need to offer an endpoint that provides fee estimates based on previous blocks, and there are discussions ongoing on the semantics of that API.
Can we get rid of the need to cache spent txos? Shouldnât the utxos by definition not contain any spent txos?
When you build a transaction using UTXOs and send it to the Bitcoin network, in theory youâve spent these UTXOs and shouldnât use them again for other transactions, but until this transaction is mined in a block, its UTXOs are still considered unspent by the Bitcoin network, and thatâs why you currently need to cache them locally (until they are mined).
We have considered an alternative API for get_utxos where, when you send a transaction using send_transaction, the Bitcoin canister will mark these UTXOs as spent in its local state, so then clients wonât need to cache these transactions themselves. @dieter.sommer maybe this is something worth revisiting?
With the API provided, are we able to deploy bitcoin smart contracts (as in code running on the bitcoin blockchain)?
I am not sure what you mean by code running on the bitcoin blockchain. Are you referring to Bitcoin script? Can you provide an example of what you have in mind?
1 Like
Please this sounds great!
2 Likes
Let me get back to you on this later today
1 Like
Very excited for this
1 Like
The API is designed so that the return value of get_utxos depends only on the state of the Bitcoin blockchain visible to the Bitcoin canister. This is a nice feature when analyzing the security properties of the Bitcoin canister.
Having the Bitcoin canister cache recently spent outputs would have the side-effect that querying the UTXOs of an address may not return the same set across subnets because the subnets may cache different transactions.
I see the following approaches:
- We investigate if there is a way to add a transaction cache that is consistent with our security analysis.
- More user-friendly Bitcoin libraries building upon the low-level API are made available to developers.
In the end, it may not be so important because it will be easier (no need to worry about UTXOs!), cheaper, and faster to work with âwrappedâ Bitcoin.
1 Like
Sorry if this question has already been asked or if it is trivial, I am trying to understand the sharing of a private key of some Bitcoin wallet on the IC. This happens through threshold signatures and the point is that in a subnet, shares of a private key are shared so that the shares on their own donât reveal anything, but combined gives access to a Bitcoin wallet. I am trying to understand if it is possible for nodes in a subnet to collude and collect the shares of the private key of some BTC wallet. How are the shares of a private key stored and please explain why can other nodes not access them?
3 Likes
I would love to see Dfinity produce a video, similar to the one below, explaining how key sharing for this bitcoin subnet works. @JensGroth did a great job explaining all this for the standard subnets and I think a video tailored to the BTC integration (even if there are only a few differences) would be a helpful resource.
8 Likes
Let me briefly summarize how this works. We use threshold cryptography for realizing ECDSA signing, which means, as you say, that an ECDSA private key is secret shared over the nodes of a subnet. Each node holds its own secret share and contributes to the signing protocol. A minimum threshold of nodes is required to compute a signature. Nodes only hold their shares.
The trust model of the Internet Computer implies that strictly fewer than 1/3 of the nodes of a subnet can be compromised without compromising the security of the subnet. If less than 1/3 of replicas are compromised and get together to combine their secret shares, they have no information whatsoever about the ECDSA private key as they are fewer than the required threshold. Clearly, if sufficiently many parties collude in this way to use their secret shares, they will be able to compute signatures on any message or reconstruct the key from their shares. Thatâs unavoidable as itâs the core of threshold cryptography.
Some notes on key management:
There is 1 master ECDSA private key from which we derive a âroot keyâ for each canister. Each canister can then derive (or ask the system to derive) an infinite number of keys for itself, and thus can compute an infinite number of Bitcoin addresses.
We will use large subnets, initially 34 nodes, for threshold ECDSA.
Hope this helps answer your question.
7 Likes
Having a video in this style for threshold ECDSA would be great. Let me bring this suggestion up internally so we can see whether / when we can do something like this.
Thank you for your suggestion!
6 Likes
We will use large subnets, initially 34 nodes, for threshold ECDSA.
Oh interesting, isnât 34 huge? Bigger than any subnet right now, including the NNS subnet I think?