ckBTC: a canister-issued bitcoin twin token on the IC, 1:1-backed by BTC

General
90

Hello everybody!

DFINITY will submit three proposals today, which matches the outcome of the discussion wrt ckBTC & KYT (ckBTC and KYT Compliance - #414 by Jan).

  1. First, to install this Chainalysis KYT canister without any principals that can set API keys. This will let everybody review the Chainalysis KYT canister code.
  2. Second, a proposal sets an initial list of principals that can provide API keys. This proposal will contain Toniq’s principal. Anybody else that is willing to obtain a chainalysis subscription and perform the role of providing API keys can submit a proposal similar to this to add their own principal (and feel free to ask for help here).
  3. Third, a proposal to upgrade the ckBTC minter to use this KYT canister and enable BTC → ckBTC conversions. This proposal will also reduce the required confirmations from 72 to 12.

We will share the proposals here and I hope everybody takes the time to vote!

12 Likes
91

For verification purposes, this is the Toniq principal that will be included in the proposal.

pzc5r-ctmyf-4menu-zt2d3-y57i4-hodcg-dfvpi-bfj3w-7jqef-d7s35-xqe

5 Likes
92

Do we have finalisation on the rewards model for API providers?

93

The proposals have now been submitted:

  1. Install the KYT canister Proposal: 115468 - IC Dashboard
  2. Update to configuration of the KYT canister Proposal: 115470 - IC Dashboard
  3. Upgrade the ckBTC minter Proposal: 115473 - IC Dashboard

Please vote and help spread the word! If you have any clarifying questions or need help verifying certain parts of the proposals, please don’t hesitate to ask in this thread.

12 Likes
94

Yes, proposal Proposal: 115473 - IC Dashboard proposes to set a fee of 2000 sat (currently ~0.57 USD) for a KYT request. You can see this fee being set in the upgrade args. This fee can of course be changed with future NNS proposals.

5 Likes
95

Why was a reduction in the number of confirmations mixed in with the KYT introduction? Does the presence of KYT make it safer in any way to accept less confirmations?

96

We’ve been meaning to reduce the min confirmations anyway, but now was a good time because it mainly affects how long converting BTC into ckBTC takes, and this proposal opens up that conversion.

97

Part of the problem with how the whole governance and DAO release structure works

Someone will feel strongly about a component of a change

To be done right, every small part would be put to motion and change proposals

Then you’re left with overhead, bureaucracy and lack of delivery

Perhaps the lesson is, there is a time and a place for DAOs, and it might not be at early stages, and maybe one for builders to keep in mind

98

Anyway, congratulations on the successful completion of the update.
Now it seems to be possible to wrap with ICLight House, is it safe to do a test money transfer?

99

I don’t think it’s ready yet, I’m getting the following error:

(
  variant {
    Err = variant {
      TemporarilyUnavailable = "Failed to call KYT canister: management call \'fetch_utxo_alerts\' failed: canister error: IC0503: Canister pjihx-aaaaa-aaaar-qaaka-cai trapped explicitly: Panicked at \'failed to register transfer: (SysTransient, \"Couldn\'t send message\")\', rs/bitcoin/ckbtc/kyt/src/main.rs:643:6"
    }
  },
)
100

Have you tried it with a different wallet?

101

Two different wallets. One on cli, and one using plug wallet and the iclighthouse interface. Same error on both.

Would love to build with ckBTC but the current onchain liquidity is not sufficient and ckBTC isn’t cheap to acquire. Hoping it’s usable soon.

1 Like
102

I don’t know if this is the case here, but in dfx the most common cause of this error is when the canister doesn’t have the amount of cycles available that should be attached to the call. I’ll notify the team

1 Like
103

Team confirmed it was because of low cycles balance. The canister is topped up and should work again as intended

1 Like
104

I’ll just leave this right here and ya’ll can draw your own conclusions

2 Likes
105

Anything that they don’t control is a threat. Anyway, I’m guessing KYT will be favorable to them.

106

Base on DID （Canister: mqygn-kiaaa-aaaar-qaadq-cai） - ICP Dashboard, the response of update_balance is

type UtxoStatus = variant {
    // The minter ignored this UTXO because UTXO's value is too small to pay
    // the KYT fees. This state is final, retrying [update_balance] call will
    // have no effect on this UTXO.
    ValueTooSmall : Utxo;
    // The KYT provider considered this UTXO to be tained. This UTXO state is
    // final, retrying [update_balance] call will have no effect on this UTXO.
    Tainted : Utxo;
    // The UTXO passed the KYT check, but the minter failed to mint ckBTC
    // because the Ledger was unavailable. Retrying the [update_balance] call
    // should eventually advance the UTXO to the [Minted] state.
    Checked : Utxo;
    // The UTXO passed the KYT check, and ckBTC has been minted.
    Minted : record {
        block_index : nat64;
        minted_amount : nat64;
        utxo : Utxo;
    };
};

I got below response, which I don’t understand, anyone can help?

(
variant {
3_456_837 = variant {
3_041_074_078 = record {
1_790_128_894 = 12 : nat32;
1_987_561_304 = null;
}
}
},
)

107

So we was able to make the BTC work in the wallet, if somebody wants to give it a try.

108

I think part of the solution here, potentially, is to deploy canisters that aren’t controlled by the NNS.

I think this is an extremely important issue, retaining write permissions to canisters like ckBTC may implicate these AML laws.

109

If you download the candid interface and give it to dfx canister call using --candid path/to/can.did, it’ll decode the fields for you

1 Like