I think it comes close enough and covers my use case. Thanks for pointing this out. I did not know that withdrawals work like that.
What happens if I submit 40 retrievals in short succession? Is the logic smart enough to create two withdrawal transactions in parallel from non-overlapping UTXOs? Or does it do one and wait for confirmations before doing the second one?
Actually, the ckBTC minter can handle up to 100 retrieval requests in a single Bitcoin transaction.
20 is simply the threshold for the creation of a transaction, but it is possible that the number of pending requests grows quickly (beyond 20) between checks.
And yes, it uses completely different UTXOs for each withdrawal transaction, so there is no waiting time unless the ckBTC minter runs out of UTXOs and is forced to wait for the change of pending transactions to become available.
According to the metrics, the ckBTC minter currently has more than 9000 UTXOs available, so this risk is small.
How long is it expected to take for the ckBTC to see a confirmation relative to a public block explorer? I mean the delay from when a public explorer sees a new confirmation on a utxo until a call to update_balance sees the new confirmation on a pending utxo. This is the
combined delay caused by the Bitcoin canister receiving and processing the new block and the ckBTC minter seeing the new confirmation from the Bitcoin canister.
I tried it once and the delay was about 1-2 minutes. Is that expected?
The ckBTC minter currently has a withdrawal (= retrieval) minimum of 50,000 sats (~$50). Does it make sense to reduce that minimum to 10,000 sats now? Network fees are around $1.5 per transaction so a minimum in the order of $10 seems reasonable.
When a new block is mined, the Bitcoin adapters should pick it up quickly, say, in a few seconds. It is then added to an IC block and made available to the Bitcoin canister, which should be quick too.
However, ingesting the block takes quite some time, currently about 20-30 seconds. After that, any new UTXOs will be returned in get_utxos calls.
We never measured the delay. I would expect that it usually takes more than 30 seconds but not more than a minute.
If you have concrete measurements where it takes considerably more than a minute, then we should investigate this.
The minimum retrieval amount was reduced from 100,000 to 50,000 sats not too long ago.
Since ckBTC is burned first and never reimbursed, the ckBTC minter’s Bitcoin transactions must go through eventually. A relatively high minimum retrieval amount ensures that the replace-by-fee mechanism can be used, even repeatedly, continuously increasing the fee (paid by the user) until the transaction is mined in a block.
In short, the minimum retrieval amount is kept relatively large for security reasons as it increases the chances that a transaction can be pushed through and the ckBTC minter gets the change back.
I measured between 1:20 and 1:35 (the two times I probed). But that is relative to the timestamp in the block. I couldn’t find a block explorer that shows me when they first saw the block. So the real time could have been very different. So I’m guessing it’s all in line with what you said.
The answer is useful for frontends because the frontend has to decide, after having seen a 6th confirmation, when to call update_balance. I will work with 1 minute then.
As we have turned on Bitcoin testnet canister for testnet4, we have re-deployed ckTESTBTC canisters (minter/ledger/index/checker) and they are now ready to use:
minter: ml52i-qqaaa-aaaar-qaaba-cai
index: mm444-5iaaa-aaaar-qaabq-cai
ledger: mc6ru-gyaaa-aaaar-qaaaq-cai
checker: o6ude-eyaaa-aaaar-qal6a-cai
All state was reset. The minter has a min retrieval amount of 5000 sats, and check fee 100 sats (and the checker was set to AcceptAll). The ledger’s transfer fee is 10 sats.
You can get testnet bitcoin from any faucets that support testnet4, and start converting them to ckTESTBTC now.