For the ICP community! How to get the number of Bitcoin confirmations from the ckBTC Minter

Developers
1

I am planing on making something somewhat related to this: Faster BTC->ckBTC minting/deposits

Open source for the community. Service will be blackholed and open source so people can trust it.

I am midway through making it however the documentation for the minter is a little be confusing. I am calling update_balance and trying to find out what i need to look for in the response to this call (or perhaps a different call idk) to find out what the current number of confirmations is for a specific amount of bitcoin going to a specific principal and subaccount:

basically i need the amount and the current_confirmations

this is the error response form update_balance

image
image1224Ă—454 46.2 KB

image
image1066Ă—210 21.8 KB

any help is very much appriciated

1 Like
2

If you get an UpdateBalanceError, the information you need is right there:
The pending_utxos array contains the UTXOs that do not have enough confirmations yet. If you look at any particular PendingUtxo, confirmations tells you the current number of confirmations (which is lower than required_confirmations) and value is the amount locked in this UTXO.

Does that answer your question?

1 Like
3

Thank you so much! Can you also explain what is meant by a few things in this response:

export interface Utxo {
  height: number;
  value: bigint;
  outpoint: { txid: Uint8Array | number[]; vout: number };
}
export type UtxoStatus =
  | { ValueTooSmall: Utxo }
  | { Tainted: Utxo }
  | {
      Minted: {
        minted_amount: bigint;
        block_index: bigint;
        utxo: Utxo;
      };
    }
  | { Checked: Utxo };

What does Tainted, Checked and ValueTooSmall mean??

4

All three statuses indicate that no ckBTC was minted for this UTXO.

ValueTooSmall means that the UTXO locks an amount that is smaller than the (KYT) fee. Since no KYT check can be performed, the UTXO is ignored. It is very important to send more than this fee (currently 2000 sats) to the ckBTC minter!

Tainted means that the KYT check found that there is something “wrong” with this UTXO (for example, it is tied to some illicit activities including scams and money-laundering). In this case, the UTXO is quarantined (and no ckBTC will be minted).

Checked means that the KYT check was successful but the ckBTC could not be minted, for example because the ckBTC ledger was being upgraded in that moment. In this case, the caller should just retry the update_balance call.

2 Likes
5

Hey final question what does AlreadyProcessing mean for the ckBTC minter??

6

The ckBTC minter only handles one request per principal ID at a time.
Specifically, if it receives an update_balance or retrieve_btc request and such a request is currently being processed for the same principal ID, then an AlreadyProcessing error is returned.

This guard is in place to prevent double-minting (of ckBTC) and double-spending (of bitcoin).

1 Like
7

image
image1514Ă—758 76.8 KB

Is there any way of changing this or making this smaller? What is the reason that this is so high?

8

The minimum retrieval amount could be changed through a proposal with the corresponding code change.
However, there is a reason why it is so high: When a retrieval request is processed, the desired amount of ckBTC is burned first. This operation is irreversible, so the same amount in BTC (minus fee) must be released to the user. It is possible that fees go up so much that the transaction will sit idly in the mempool and is possibly dropped (leaving the user with neither ckBTC nor BTC).
The ckBTC minter can handle this situation: It (periodically) re-submits the transaction with an increased fee, which means that the user gets less because the user pays for the fees.
This is only possible if more can be deducted from the amount that is paid out—ideally leaving a big chunk for the user. The minimum retrieval amount of 1 mBTC ensures that it is very likely that a transaction will eventually be mined in a block, even if the network fee increases, and that the user still gets some BTC as a result.
In other words, the minimum retrieval amount could be reduced but that would increase the risk that a user cannot get any BTC out at high fee rates.

3 Likes
9

mhh, the key issue is probably that we cannot know if the broadcasted tx is still sitting somewhere in the memepool, right?

otherwise it might be worth thinking about a fallback-mechanism where the burned ckBTC are re-minted to the user when we could be certain that the tx is dropped from the memepool.

in any case the UX would suffer a lot and the user would be “stuck” on ICP for a while :sweat_smile:

thanks for raising the question @jake-beardo, definitely worth knowing for anybody :+1:

1 Like
10

Exactly. The ckBTC minter cannot know whether the transaction will still be confirmed in a block at some point in the future.

11

Proposal 133462 was submitted about reducing the min withdrawal amount to 0.0005 BTC. This seems like a reasonable reduction, nice for users to be able to withdraw smaller amounts and still big enough such that the chance of stuck transactions should still be minimal. DFINITY plans to vote in favor.

2 Likes
12

although the risk is minimal. how would we address the unlikely case of stuck transactions? :thinking:

1 Like
13

It increases the fees until no longer possible (which is why we have the min withdrawal amount), and if that’s not sufficient, it needs to wait until fees come down and the tx goes through. In case there would be a transaction stuck for a long time, things could probably still be managed with an NNS proposal to upgrade the ckBTC minter based on the unexpected circumstances.

Note that the ckBTC minter already dynamically increases the min withdrawal fee whenever bitcoin network fees go up, so the only way this issue could occur is if fees rise very quickly. Overall, this scenario seems very unlikely to occur.

3 Likes
14

Amazing that is excellent news. Once the motion goes through who is expected to make the code change and submit a new proposal? The community (i.e. me) or Dfinity? If the community is expected to make the change are you able to offer any quick advice on the best what to do that? I notice that the minimum withdrawal amount is a init variable to the minter hence is there just a cd pipeline or config file somewhere that i need to change where that variable is currently set or something?

Thanks in advance!

2 Likes
15

Let’s first wait for the motion to really pass, but assuming it will get adopted, either path is possible. To change the value, we just need to upgrade the canister, such that we can pass in the new value via the upgrade arguments. Note that we don’t actually need a code change, so we can “upgrade” to the same wasm we used before.

It would be great to have more people submit NNS proposals that make real changes, so if you’re up for it, you could definitely do it and we can offer some help. Alternatively DFINITY can submit the proposal.

16

Hi @Manu Looks like the proposal has over 50% !!! which is awesome. Unfortunately I am absolutely swamped with work at the moment and have no idea about how I would go about submitting the proposal. If its something we can do together on a 30 min call that would be awesome and I would be happy to submit it myself so that I know how to in future. But if its something that would take longer then I might have to defer to dfinity. If we were to do a call what would be the best way to contact you?

17

Ok, if you’re swamped then it’s probably easiest if DFINITY picks it up and submits the upgrade proposal.

18

Thank you, What tends to be the time schedule on a change like this?

19

We plan on submitting the proposal on Friday

20

We actually ended up submitting the proposal now: 133840.

1 Like