So this whole discussion is about the risk of tainted BTC entering the ckBTC ecosystem and then an innocent ckBTC getting stuck with tainted BTC when they cash out.
What if the BTC is pooled together, so for example, if there are 100 BTC then if is withrdraw 1BTC, that BTC is made up of 0.01% off all the 100BTC. So that way everyone who withdraws will get like 0.01 of tainted BTC that is just all mixed in.
ckBTC is just a tool for tx, i think KYT is a thing for business or dapps on ICP to do rather than a responsibility of ckBTC.
This was tainted BTC just becomes normalised and excepted by all the users of ckBTC.
Maybe this makes ckBTC less attractive as you guaranteed will receive tainted BTC but so will everybody else so then tainted BTC is more normalised and then less effecting on price.
Maybe this is unpractical as it makes too make BTC network tx/s which is more cost and time and work for the network.
Just a rough idea. i am quite uneducated on KYT tbh.
instead of trying to fight tainted BTC why don’t we accept it and make it a norm for all BTC to be mixed so when anybody withdraws ckBTC for BTC they guaranteed will get a mix all of all BTC that entered and by logic some mixed in tainted BTC.
Hi @Manu & @THLO , is there a progress update you are able to give us ? Ideally with some information on when the changes to remove Chainanalysis KYT will take place. It would be great to have my BTC back
Hi @Krazy, sorry for the long wait and the lack of updates.
The new mechanism is nearly feature complete and the internal security review is about to kick off.
Barring any unforeseen circumstances, we should be able to provide a roll-out plan soon (i.e., in weeks and not months).
Since you asked about getting “BTC back”, note that the new mechanism will make it possible to re-evaluate your deposit so that you’ll get your owed ckBTC. Of course, you’ll be free to convert them back to BTC whenever you want.
Good news: The security review has started! We expect that the code will pass the review without any major findings. The current plan is to submit the upgrade proposal on December 6 (St. Nicholas Day )!
It is important to note that, once upgraded, the ckBTC minter will not automatically re-evaluate all ignored/quarantined UTXOs. For technical reasons, it checks all UTXOs associated with a given principal ID when the owner of this principal ID sends an update_balance request.
Note that the NNS frontend dapp makes this call automatically. If you sent bitcoin to the address derived from your NNS frontend dapp principal ID, it is enough to log into the frontend dapp and have it check your ckBTC balance.
The new mechanism is simple: Bitcoin addresses are compared against a blacklist. Bitcoins coming from one of these addresses are quarantined and requests to send bitcoins to one of these addresses are rejected.
You may be wondering why it took quite a while to implement this functionality. The main reason is that outputs do not contain the information what Bitcoin addresses spent bitcoin in the transactions that generated these outputs, so this information needs to be fetched reliably using HTTPS outcalls.
Some updates regarding ckBTC and the new Bitcoin Checker canister:
Chainalysis KYT is now removed and conversions (both for deposits BTC → ckBTC and withdrawals ckBTC → BTC) go through the new Bitcoin Checker canister .
It was, however, a bumpy start:
The initially deployed bitcoin checker with proposal 134413 had a bug in cycles accounting: it was attaching cycles for HTTPs outcalls as if it were on a 13-node subnet, which is obviously insufficient when running on the fiduciary subnet (34 nodes).
This was fixed with the version in proposal 134436, but we must have been tired as we made a rookie mistake , the changes in the canister’s configuration, which is stored in stable memory, was not backwards compatible and so the upgrade failed .
Third time is the charm as they say and we reinstalled the bitcoin checker canister with the same wasm as in the previous proposal with proposal 134442 which was this time successful and some UTXOs have been minted already
We are not out of the woods just yet , since out of the 3 providers that the Bitcoin Checker canister can use, 2 have put in place what seems to be new rate-limit restrictions that were not triggered when we first tried those providers out. That means currently, only one provider is functioning properly and we also hit there sometimes the rate limit .
This is unsatisfactory and we are actively working towards improving this situation. So please bear with us and we will keep you posted of any new development .
I hope this applies to the ICPS DEV team that rugged the IC community it was a tactic where they use the new staking miner system, it seems they have left the token on ICPSwap but stole all the staked miners but closing the miners check for yourself at icps.fun
The next step is to start storing Bitcoin blocks, probably also with the functionality to backfill. This functionality will be useful for applications that need to process whole blocks.
Looking up specific transactions would require building an index, which would consume a lot more memory compared to just storing serialized blocks (and storing all the blocks would already consume roughly 600 GB).
Is there any documentation on the new Bitcoin checker? I saw by using it that the checker fee is 100 sats. And how does it work internally? Does it only check 1 hop from the blacklisted addresses? Or does it go further back and calculate a taint percentage?
The question is also why charge the checker fee at all? If it is just a canister comparing the address against a list then there is no cost except for cycles. The fee does not prevent spamming beyond what the Bitcoin network fee already does. I am asking not because I think it is too expensive for the user to pay the ~10 cents. I am asking because it complicates frontends when they have to explain to the user that there is a difference in amount, say 0.0001 BTC were deposited but only 0.000099 ckBTC were credited. It creates a new amount that the user does not recognize as easily as his. It would be easier if the amount was the same. If there was a real cost like in the past with the external KYT provider then of course the fee would be necessary. But now it seems we can do without it and improve the experience.
You are right, documentation is currently lacking as I was busy with other tasks. I’ll try to update the documentation next week.
There is a checker fee when depositing and a ckBTC minter fee when withdrawing bitcoin. There is no checker fee in the withdrawal flow because it is literally just a lookup in the blacklist.
However, in the deposit flow, the ckBTC minter gets a new UTXO, which points to a previous transaction. The Bitcoin checker must determine if any input of that transaction is blacklisted, which means that it needs to perform potentially many HTTPS outcalls to fetch transaction information because this information is not available on-chain. Since this is a costly operation, a fee of 100 sats is charged, which should be sufficient to cover the cycles spent on HTTPS outcalls on average.
Hi @bls_sigmature.
I’m not sure if you’re asking about the KYT canister, which the ckBTC minter no longer uses, or the new Bitcoin checker canister. Assuming you’re interested in the current mechanism, here are my answers:
The NNS controls the Bitcoin checker canister. This canister handles all requests on its own, without any dependency on external KYT providers, so there is no way to participate in the process.
A fee needs to be paid when depositing bitcoin because the ckBTC minter needs to pay a fee in cycles to the Bitcoin checker canister, which it turn uses the cycles to pay for HTTPS outcalls.
The ckBTC minter keeps the 10 ckSats for itself. It will eventually sell the collected ckBTC for cycles to pay for its own compute and storage costs. However, this mechanism is not implemented yet.
I hope this helps. If you have any follow-up questions, let me know!
)!
and conversions (both for deposits BTC → ckBTC and withdrawals ckBTC → BTC) go through the new Bitcoin Checker canister 
.
, the changes in the canister’s configuration, which is stored in stable memory, was not backwards compatible and so the upgrade failed 
.
as they say and we reinstalled the bitcoin checker canister with the same wasm as in the previous proposal with proposal 
, since out of the 3 providers that the Bitcoin Checker canister can use, 2 have put in place what seems to be new rate-limit restrictions that were not triggered when we first tried those providers out. That means currently, only one provider is functioning properly and we also hit there sometimes the rate limit 
.
.
