Hey there! That’s a great question about the integration process for Bitcoin, ckBTC, Ethereum, and third-party-chains. It would be interesting to know if there’s a working group or something similar to help streamline the integration process and ensure security. Understanding the timeline and features would definitely be helpful in making informed design decisions.
2 Likes
Hi @Kaburaha!
First of all, welcome to the Internet Computer Forum!
Regarding your question: We are in the process of shaping a working group. Currently, the discussions are focussed on Ethereum integration and done on the forum: Long Term R&D: Integration with the Ethereum Network - #54 by Roman
If you follow this topic and the one here, you will be getting most of the current discussions related to integrations. Also, you will get the relevant information for the upcoming WG.
5 Likes
Hi everybody!
The bitcoin canister has been running successfully for more than half a year now. During this time, DFINITY has of course kept a close eye on whether everything was working as expected. We set up some tooling that queries the height of the Bitcoin canister, and compares it to what various block explorers have, such that alarm bells would go off if they disagree too much (which was never the case!). This monitoring currently relies on DFINITY’s involvement, and we thought we could improve things further by instead having this monitoring system run as an autonomous “watchdog canister” on the Internet Computer. We now made progress on this idea and would like to propose this more concretely to the community.
The watchdog canister (source on github) regularly queries a list of block explorers via HTTPS outcalls to obtain their view of the latest Bitcoin block height. More precisely:
- It queries all block explorers on the list to obtain their view of the latest block height.
- Some explorers may temporarily be offline, so it filters out all errors, and only continues with the successful results. If less than three blockchain explorers respond successfully, then the watchdog failed to establish the block height this time, and does not take further action until the next check.
- It defines its “target block height” as the median of all heights returned by the block explorers. It uses the median such that one block explorer returning an incorrect height cannot influence the target height.
- It compares its target height with the block height that the bitcoin canister currently has. If this differs by more than 2, something must be wrong. This would be a dangerous scenario as canisters that build on the Bitcoin integration (such as ckBTC) may now get inconsistent information from the Bitcoin canister, which can have serious consequences. We propose that the watchdog canister can pull the emergency brake in such a scenario, and temporarily pause the Bitcoin canister from responding to requests: it is better to return an error than to give information that may be incorrect. It would re-enable access whenever the Bitcoin canister and Bitcoin explorers agree again. If the divergence can only be fixed through an upgrade to the Bitcoin canister, then access to the Bitcoin canister would only be restored as soon as the upgrade proposal is accepted and the Bitcoin canister caught up to the latest Bitcoin height.
We view this watchdog canister as an additional safety mechanism, much like airbags in a car: we never expect this mechanism to kick in, and based on the historical data it would have never intervened in the half year since the launch of the Bitcoin canister, but in the unlikely event the Bitcoin canister and block explorers have a different view of the current height, it seems prudent to temporarily pause the Bitcoin canister access.
Unless there are concerns, DFINITY plans to submit proposals in the coming weeks to
- Install the watchdog canister under NNS control
- Update the Bitcoin canisters (mainnet and testnet) to allow the watchdog canister to pause and unpause its operations
Please let us know what you think! We’d be happy to hear your feedback and to answer any clarifying questions here.
18 Likes
HI.Excuse me,Is there any progress on the above proposal? What is its specific priority?
Thank you very much!
These proposals are now open for voting:
- Proposal: 123101 - ICP Dashboard (BTC testnet)
- Proposal: 123106 - ICP Dashboard (BTC mainnet)
5 Likes
There are plans to start a working group on this topic soon, so hopefully you can follow the progress there soon.
6 Likes
Hey everyone! DFINITY this week has submitted two seemingly identical proposals to upgrade the “Watchdog Testnet Canister”:
In case you’re unfamiliar, the “Watchdog Testnet Canister” is a monitoring canister that queries external block explorers and compares their tip with the Bitcoin testnet tip that’s available on the IC. Whenever it detects a divergence, it disables the Bitcoin testnet API out of precaution. You can read more about the watchdog canister in Manu’s post above.
As mentioned in the proposal summaries, we’re upgrading the canister to make it more robust and less noisy. We’ve unfortunately made a mistake when submitting proposal 127120 - we didn’t include the canister’s initialization arguments in the proposal. We’ve corrected that in proposal 127121. Thus, DFINITY plans to reject proposal 127120 and adopt proposal 127121.
If you have any questions please don’t need hesitate to ask.
5 Likes
Folks, we were in the process of upgrading the Bitcoin testnet canister this week. You may have noticed that DFINITY rejected proposal 127667, as it was unintentionally proposing to reinstall the Bitcoin testnet canister, rather than upgrade it.
This proposal has been resubmitted, with the correct upgrade mode, in proposal 127681.
We’re discussing now as well how we can make the upgrade mode more visible in proposals to avoid these issues from reoccurring in the future.
4 Likes
Hi everyone,
I wanted to share an update about the Bitcoin testnet canister. As some of you might have noticed, the Bitcoin testnet canisters has not been responding to requests for about 2 weeks now. The reason for this is that it got trapped into the wrong fork of the chain after one of the “block storms” that happen during a difficulty reset on the testnet network.
The reason for that was the use of a lower stability threshold (50 instead of the more appropriate 144 one). This change had been made in the past in response to previous issues as a temporary measure but it was not reverted after those issues were fixed with some of the last upgrades.
In order to resolve this, we have decided to re-bootstrap the Bitcoin testnet. This means computing its state offline up to some height and having the canister start from that point onwards. This process involves two NNS proposals, one to install an uploader canister which is used to upload pre-computed state and another one that upgrades to the Bitcoin canister Wasm and continues syncing from that height on.
Over the last couple of days, we attempted to submit the first proposal of the process. Unfortunately, because the process is undocumented and was pieced together from past notes, there were 2 proposals that were submitted that are wrong (incorrect wasm and missing init arg respectively) and the DFINITY Foundation plans to reject as a result. These are proposals 133164 and 133179. We plan to improve the documentation of the re-bootstrap process better to avoid this in the future.
We invite the community to adopt proposal 133186 which is the correct one to install the uploader canister so that the process of uploading the state can start.
5 Likes
Working on it, meanwhile :