Hey @dsarlis and or @Manu can we have an update on why Dfinity ended up rejecting proposal 133414 nd thus allowing testnet to continue syncing ? Much appreciated.
Yeah we saw the situation on testnet calm down, so both testnet and mainnet are working without issue at the moment. Since people do in fact want to use the BTC testnet integration, we thought it was better to keep it enabled with the knowledge we have now.
That being said, weâre working on some long term improvements to get out of the challenges that weâve been having with testnet.
5 Likes
Great, thanks for the quick update.
Voted to reject proposal 133414 based on this later feedback by DFINITY.
Build successful and hashes match.
@Manu has the reason for the previous impact that the testnet had on the mainnet which resulted in this proposal in the first placed been figured out and why it has suddenly stopped?
Hi everybody!
DFINITY would like to propose some changes to ICPâs bitcoin integration.
What problems are we seeing today?
- Bitcoin testnet (testnet3) is not in a great state. In the past months, the testnet has been frequently plagued by âblock stormsâ, where the block rate goes much higher than intended. Bitcoin is designed to create one block every 10 minutes, but on testnet, blocks occasionally appear at more than 100x that speed. This also leads to frequent long forks, the likes of which are unthinkable for BTC mainnet. ICPs Bitcoin integration has not been designed to handle such block storms or very long forks. This meant that the BTC testnet API was often unavailable (because the bitcoin canister was still busy syncing testnet but unable to keep up with a block storm), and it has even gotten stuck on a 50+ block long fork, requiring a reinstall of the bitcoin testnet canister.
- Itâs difficult for DFINITY to quickly respond to issues with BTC testnet as itâs governed by the NNS and specified in the interface spec of ICP.
- Bitcoin testnet is also difficult to use because TBTC, the testnet bitcoin token, has become difficult to obtain. This somewhat defeats the purpose of a testnet.
How are we proposing to improve it?
- Mark the BTC API in the interface specification as deprecated, and encourage canister developers to call the BTC canisters (BTC mainnet canister, BTC testnet canister) directly rather than through the management canister. The interface specification of the bitcoin canisters will move to a separate document. This change will remove the need to have the BTC API defined in multiple places, and make calls slightly faster for developers. Eventually weâd hope to remove the BTC API entirely from the interface spec, but we would need to make sure that the API is not getting meaningful usage anymore first.
- Move control of the BTC testnet canister (and the corresponding âwatchdogâ canister gjqfs-iaaaa-aaaan-aaada-cai) to DFINITY. Since this is only testnet, itâs not security critical so itâs acceptable to be centrally controlled, and this allows DFINITY to iterate quickly and address any issues without additional delay from governance proposals. This proposed change is related to step 1, removing the BTC API from the interface specification, as it would not be acceptable for DFINITY to control a canister that implements part of the interface of the Internet Computer, but we now believe that the bitcoin testnet API should not have been part of ICPâs interface specification.
The Bitcoin mainnet canister would of course remain under NNS control. - Change the Bitcoin testnet canister to use Bitcoinâs testnet4, rather than the current testnet3. Testnet4 includes code changes to how the mining difficulty can be adjusted, which should avoid block storms (details can be found in BIP 94). Also testnet token availability for testnet4 is currently much better than for testnet3.
Please let us know what you think!
19 Likes
Hi Manu, when can we expect to have ckBTC upgraded with these changes? Can you clarify what will happen with the ic_btc_interface types? Btw, there were some type mismatches between, e.g. ic_btc_interface::Utxo and ic_cdk::api::management_canister::bitcoin::Utxo â how is it gonna be after the upgrade?
Use Testnet4 is better.
Proposal 133787 to Increase Bitcoin Testnet Canister WASM Memory Limit is live.
Great questions, but i dont have a full answer yet.
- Wrt timeline: as soon as possible, but since a lot of people are also busy with the heavy load on mainnet, I canât give a precise estimate now.
- I dont know in detail yet, but i think the guiding principle would be to make it as easy as possible for canister devs to switch to talking to the BTC canister directly. Ideally, I hope that we can change some cdk methods such that devs mainly need to upgrade to the latest cdk and thatâs it.
1 Like
Exactly, DFINITY submitted this proposal to increase the wasm memory the bitcoin testnet canister can use, and will vote later today. This change is needed because of the large amount of unstable blocks that weâre currently seeing on testnet, which leads to the current wasm memory limit being insufficient and calls failing. This is one of the things that would be improved by switching to testnet4.
4 Likes
Voted to adopt proposal 133787 as the reasoning is sound and the payload matches the description. The proposal increases the wasm memory limit of the bitcoin testnet canister from 3GiB to 3.75GiB in order to cope with the current influx of unstable blocks. As explained in the link, a hard limit of 4GiB applies and wasm memory limit should be set below this in order to prevent a canister from failing irretrievably.
2 Likes
Voted to adopt proposal 133787 since the canister id is correct and the wasm_memory_limit value from the description in the summary matches the payload. More info on the reason behind this here.
Canister id and wasm_memory_limit value in the payload match the description.
Voted to adopt.
1 Like
Voted to adopt proposal 133787. The proposal increases the Bitcoin Testnet Canister wasm_memory_limit from 3GiB to 3.75GiB because of the large amount of unstable blocks are explained here. The proposal summary matches the problem described by DFINITY and the payload matches the solution proposed.
1 Like
Approved proposal 133787, new wasm_memory_limit corresponds to the target explained here. The proposed change is reasonable.
Update: We just submitted proposal 133899 which adds a DFINITY principal 47gy6-2c22d-voqoy-eflbe-gwml3-zwe52-r6lx7-rexro-ebluo-2rqcd-sae as controller of the BTC Testnet canister.
3 Likes
Adopted proposal 133899. Payload matches the summary and the motivation makes sense.
2 Likes
ADOPT proposal 133899 the payload matches the intention in the summary.
2 Likes
Voted to adopt proposal 133899. Reasoning provided in the forum post matches the proposal summary and payload.
1 Like
Proposal 133899. The payload aligns with the summary, and the motivation is sound.
1 Like