In any case, we are happy to accept that “make yourself one of the receivers if you want to know whether a transfer-out is included in the chain” as an answer for now.
But it would be good if a more general API that can query status of arbitrary txid can be provided in the future. Thanks!
Noted, thanks for your feedback.
Having an API to query any bitcoin transaction (spent and unspent) was ruled out initially because of the storage requirements. We’d need to store 100s of GiBs of additional state.
One idea would be to support this API for only “recent” transactions (e.g. transactions from the 24 hours). Another idea would be for the canister to use the HTTP API to fetch this information from some external API.
We can iterate on this and figure out the best step forward as we collect more feedback.
hi, when will we have BTC integration beta? Where can I track it?
Hi can you give us any update?
Update
Here’s an update on where we stand with the Bitcoin feature (apologies for the few responses recently, it’s been too busy 
):
The Bitcoin feature is code complete and we are currently finishing the documentation. On the threshold ECDSA front, we are very close to get something out to mainnet (actually, we have been out already briefly, but needed to address two issues and turn the feature off again, one in the implementation of message routing that routes the calls to the ECDSA functionality to the ECDSA-enabled signing subnet, and another one that is related to a technical issue that lead to a problem when upgrading the threshold ECDSA subnet). Hotfixes for both are out or on their way, so t-ECDSA should be on IC mainnet soon.
The release of Bitcoin integration and threshold ECDSA beta / Chromium with Bitcoin testnet integration and a test threshold ECDSA key is imminent. A release in the coming week or the one thereafter is a probable scenario if we don’t hit any further unexpected issues.
Thanks a lot for the update, have a nice weekend @dieter.sommer 
Dieter,
My gut is telling me these snags are much larger. If you pull this off the company will get its wings.
Sorry, im not sure what you mean by this?
What I mean : many of us are hoping the current integrity of the ICP team is beyond reproach.
We are routing for you.
Peter
Any news ? There is a lot of manipulation.
Here is what said Dieter 7 days ago :
We are still “in the coming week or the one thereafter”, so let us the man work. And about any potential delay, here is what said Dieter :
This is how works the Research, and we are talking about an unprecedented breakthrough, so, again, let us the man work. Any question of that kind deprives him and the team of a precious time to dedicate to make the integration come out faster, especially those he already answered.
The Bitcoin integration seems really promising and technically fascinating, thank you for designing/implementing!
It would be useful to be able to access the Bitcoin block height in a smart contract I’d like to write, are there any plans for this in the API? (e.g. get_blockHeight)
If this were event driven (e.g onNewBlock) it would be helpful as my intention is to create a procedure that runs every 1008 blocks (~week); I’d prefer to do this with direct reference to the Bitcoin chain if possible.
We internally discussed adding an endpoint that provides information about the current state of the Bitcoin blockchain, such as the current block height.
Since we want to keep the API small for the initial release, we didn’t add it so far. But thanks for your comment! If the community feels that such an endpoint would be useful, we will look into extending the Bitcoin integration API.
Regarding event-driven actions, we also discussed options for notifications but we don’t have anything concrete yet. In the absence of notifications, you can use the heartbeat functionality to issue requests periodically.
Thanks @THLO, will keep and eye out for it…
Another primitive/library that might be useful would be a mapping of BTC addresses to ICP addresses and vice versa. To add to the mapping (and activate their smart contract BTC), a user would have to give a signed ICP address (signed with the keys underlying the BTC address).
This would allow a contract to transfer BTC between ICP accounts and allow easier deposit and withdrawal of BTC.
How do people see ICP smart contracts managing a ledger of BTC amounts?
Been 2 weeks, any update?
Hey everybody! Quick update: things are progressing well: the BTC feature to give access to bitcoin testnet has already been available for a while, and an experimental ECDSA test key is now also available (proposal 70114). This means that technically now canisters have all the tools to work with BTC testnet, but as said, all of this is experimental. This was demonstrated in our first public global R&D meeting (recording).
Next week we plan to release public documentation and example code so people can really start building!
Happy to share with everyone the first integration of btc testnet with a real app: https://spnr.app
Usage:
Will appreciate your feedback and bug reports! Many thanks to the DFINITY team for implementing & enabling this awesome feature (and threshold ECDSA too)!
I just tested, it is working really great. I received the btc almost real time using the private spinner address, see below:
@spnrapp Thanks for providing such a good demo for us to test. Really great and appreciate!
The Internet Computer is going to change Blockchain world which means that it will bring BTC to real app.
We ran into a problem:
The Replica returned an error: code 5, message: "Canister kmpi4-4aaaa-aaaal-aaqba-cai trapped explicitly: Panicked at 'Transaction too large.'
with a signed transaction of 1246 bytes.
Isn’t this too limiting? Bitcoin allows up to 100k bytes per transaction (according to this article).
Fwiw, I have pinged folks on the BTC project to take a look.