Looks like the ckBTC minter has been running for a while now on a minimum confirmation setting of 12 blocks when converting from BTC to ckBTC. A popular opinion we gathered from developers is to further lower it to have a better user experience. So we plan to submit an NNS proposal to further lower it down to 6 blocks. Would appreciate your input and support. Thanks!
6 Likes
The proposal is open for vote Proposal: 130096 - ICP Dashboard
6 Likes
I ran into a question regarding the Bitcoin address derivation used by the ckBTC minter. I found this in the ckBTC API reference:
get_btc_address(owner: opt principal, subaccount: opt blob)The provided principal ID and subaccount are concatenated to form the derivation path for the ecdsa_public_key function, which returns the derived public key. If no principal ID is provided, then the sender’s principal ID is used. If no subaccount is provided, then the default subaccount (all zeros) is used.
This public key is encoded as a pay-to-witness-public-key-hash (P2WPKH) Bitcoin address and returned as a text.
Note that the key derivation is not BIP-32 compliant, where 31 bits are used for each derivation level. Instead, a single derivation is performed based on the full principal ID and subaccount. Since the derivation is deterministic, a canister can derive the Bitcoin address for a given principal ID and subaccount itself.
I am wondering what the last sentence refers to.
Option 1: A canister can call for example the ecdsa_public_key function on the management canister and provide as canister_id in the argument the ckBTC minter and the same derivation path.
Option 2: A canister can also obtain the root public key of the ckBTC minter once and then do the derivation in its own code without having to call the management canister every time. This option is what the last sentence refers to? Is there Motoko code available that does this derivation? I found Motoko code for BIP32 derivation but not for the non-standard derivation used here.
Option 3: Non-canister code, for example a frontend, can have the root public key of the ckBTC minter hard-coded and then can also do option 2. Is there a js library available that does this?
1 Like
I think that library makes async calls to the minter canister. I am wondering if there is something that does the derivation locally.
The last sentence simply means that, given the public key and the derivation path (comprising the principal ID and subaccount), the Bitcoin address can be derived locally, i.e., there is no need to call this (convenience) function.
This argument applies to all three options - but I’m not aware of any library support.
We should get ckBTC up and running on Eth, and as soon as the Solana integration is running, get ckBTC on there too.
Bringing the battle to the home turf of other chains should be part of our strategy! And Oisy is the perfect place for it to happen. The tvl of wBTC is enormous…
Is there any documentation at least for what I have to do to derive it? I couldn’t find documentation of it.
You can check out how the ckBTC minter itself derives the public key here.
Does this help?
1 Like
I am trying to run the ckBTC minter locally, I am getting this error:
dfx canister call ckbtc_minter update_balance '(record{ owner = opt principal "shu3y-t65bi-rhvef-c7vvy-arrzh-emws6-g2uew-hpgh2-uvjqi-7s3b2-zae"; subaccount = null})'
( variant { Err = variant { TemporarilyUnavailable = "management call \'bitcoin_get_utxos\' failed: the canister queue is full" } }, )
After deploying it with this command:
dfx deploy --specified-id ml52i-qqaaa-aaaar-qaaba-cai ckbtc_minter --argument '(variant{ Init = record { btc_network = variant { Regtest }; ledger_id = principal "mc6ru-gyaaa-aaaar-qaaaq-cai"; ecdsa_key_name = "dfx_test_key"; retrieve_btc_min_amount = 10_000; max_time_in_queue_nanos = 10_000_000_000; min_confirmations = opt 1; mode = variant { GeneralAvailability }; kyt_fee = opt 100; kyt_principal = opt principal "pvm5g-xaaaa-aaaar-qaaia-cai" } })'
What’s causing this: the canister queue is full error?
Thank you!
Hi everyone 
!
Summary
Withdraw your ckTESTBTC tokens now!
Rest assured, ckBTC is not impacted.
Details
Manu highlighted some proposed changes to the ICP’s bitcoin integration, one of which being
- 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.
What this means, for ckTESTBTC:
- In the upcoming weeks, the bitcoin test canister will likely be reset to track Bitcoin testnet4 and testnet3 will no longer be available.
- At that point the ckTESTBTC canisters (minter, ledger, index and archive canisters) will be reset and tokens previously held by the minter will no longer be available.
- We therefore encourage ckTESTBTC holders to withdraw their tokens starting now.
2 Likes
Hi everyone
Some quick updates:
- Chainanalysis KYT has been removed and is no longer relevant for ckBTC, see this post for more details.
- The reason that currently only 2 out of 3 providers are not working is that there is an incompatibility between HTTP/2, which has recently been supported by HTTPs outcalls, and requests specifying the
Hostheader. Proposal 134466 should fix that issue by removing this header from requests made by the bitcoin checker canister.
3 Likes
Proposal #134466
Vote: Adopted
Reason: Builds fine and the wasm and arguments hash match, as do both fixes.
c58e00fe22 fix(ckbtc): Drop Host header from https outcall request (#3115)
The
btcscan_request function builds HTTP request for fetching raw transaction data from the BTCScan API (btcscan.org) used to set HTTP headers including Host and User-Agent now has the HOST header removed. Not sure about the errors of HTTP/2 but it matches description.57362c30e3 fix(ckbtc): state schema upgrade (#3071)
Changes to main.rs where the
init function used to initialize a canister with a configuration, now uses state::default_num_subnet_nodes() instead of a previously hardcoded constantDEFAULT_NUM_SUBNET_NODE, adding flexibility along with a centralized management for this value. Calls Config::new_and_validate to make sure input arguments are valid and stores the validated configuration into the canister state.While the
Config struct includes a default value mechanism for the num_subnet_nodes field, using serde attribute #[serde(default = "default_num_subnet_nodes")] checks that if num_subnet_nodes is missing during deserialization, it defaults to 34.
2 Likes
Proposal 134466
Vote: ADOPT
Reason: Build is successful and both code changes and hashes match.
c58e00fe22 Removed Host from request headers used for BTC API providers, since the outcalls adapter now uses HTTP/2, calls to memspace and blockstream providers would fail with a 400 error. The header was removed from btcscan too, in order to prevent possible future issues. I have been able to reproduce the issue and can confirm this commit fixes it.
On a side note I’d advise all developers who work with HTTP outcalls to update their dfx to the latest stable release, as versions <= 0.23.1 are bundled with a replica that is still using the old adapter and therefore wouldn’t experience potential issues until they deploy on mainnet.
57362c30e3 Added serde annotation to num_subnet_nodes field of Bitcoin checker’s Config struct to assign it a default value during deserialization, the config struct now also derives equality traits. A property test has been created to ensure the upgrade from an old config representation works properly, it generates config variations, which are then converted into ConfigPreviousVersion by stripping the num_subnet_nodes field, this is encoded/decoded back to Config and finally equality is checked between the original ConfigPreviousVersion and the newly decoded one converted back to ConfigPreviousVersion.
4 Likes
proposal - 134466
Vote: ADOPT
Reason:
Small fixes to BTC checker canister and all align with what is stated in the commit description. Hash and argument matches.
Hash Match: MATCH
Feedback: NONE
Proposer Check: MATCH
[c58e00fe22]
Matches description of removing Host from request_headers in btcscan_request.
[57362c30e3]
Instead of using constant DEFAULT_NUM_SUBNET_NODES for setting config in init for checker, it now invokes function default_num_subnet_nodes. This is to add backwards compatibility to state schema.
3 Likes
Hi everyone
Great news 
: Since the execution of proposal 134466, the bitcoin checker and ckBTC deposits seem to be working normally 
.
Don’t hesitate to let us know if you encounter any problem.
5 Likes
During an internal security audit we found a potential security vulnerability in the ckBTC minter. The issue hasn’t been exploited so far and we have developed a fix in a private repo that we will propose to install shortly.
In accordance with the security policy, we will disclose the details of the fix within the next 10 days, or as soon as possible. You will be able to retroactively verify build reproducibility to ensure that the deployed WASM align with the code changes.
4 Likes
This fix was adopted in proposal 135282. Below are the steps to reproduce and verify:
Repository: GitHub - dfinity/ic: Internet Computer blockchain source: the client/replica software run by nodes
Git hash: ddf05d2c70905a99b54c63520b69deef6a4fcc48
New compressed Wasm hash: ee1a74654a24a469113e752f88e51672a19eb3b8e1d7a175667c3175324b8324
Upgrade args hash: 445734292959382834da46c68370d87f8117d50271f6b8a97d5eb8dadac8cb94
Target canister: mqygn-kiaaa-aaaar-qaadq-cai
Previous ckBTC minter proposal: https://dashboard.internetcomputer.org/proposal/135200
Upgrade args
git fetch
git checkout ddf05d2c70905a99b54c63520b69deef6a4fcc48
cd rs/bitcoin/ckbtc/minter
didc encode -d ckbtc_minter.did -t '(MinterArg)' '(variant { Upgrade = null })' | xxd -r -p | sha256sum
Release Notes
git log --format='%C(auto) %h %s' 552cd582607508df70533f21e3c0bfce19f8e46b..ddf05d2c70905a99b54c63520b69deef6a4fcc48 -- rs/bitcoin/ckbtc/minter
ddf05d2c7 fix(ckbtc): use separate loops for checking and minting utxos
Wasm Verification
Verify that the hash of the gzipped WASM matches the proposed hash.
git fetch
git checkout ddf05d2c70905a99b54c63520b69deef6a4fcc48
"./ci/container/build-ic.sh" "--canisters"
sha256sum ./artifacts/canisters/ic-ckbtc-minter.wasm.gz
2 Likes
Is it planned to allow batch retrieval of BTC?
Currently, the functions retrieve_btc and retrieve_btc_with_approval allow to specify one destination address on the Bitcoin network and one amount. For the sake of speed and fee efficiency it would be nice to be able to specify a list of destinations and amounts, which should then result in a single transaction on the Bitcoin network with multiple outputs.
This feature would be highly beneficial for DeFi services that handle Bitcoin deposits and withdrawals from users. Processing withdrawals in batches will be required for scalability. If the ckBTC miner does not support it then such services will be forced to handle their own Bitcoin pool instead of being able to leverage ckBTC under the hood.
2 Likes
Technically, retrievals are already batched in that requests are first put into a queue. A Bitcoin transaction is only created when the oldest request in the queue is at least 10 minutes old or when at least 20 requests have been collected.
So, if you issue several retrieve_btc requests in succession, chances are that they will end up in the same Bitcoin transaction.
I know this is not exactly what you are asking for but maybe it already comes close. Since the fee increases per virtual byte, the savings when putting even more than 20 requests into a single transaction are small (the relatively small constant part of the fee is then already split between the 20 requests).
1 Like