Gotcha, this really complicates things… I don’t think the NNS should be controlling something this high up the stack. Implementing KYT restrictions here sets a really negative tone for the NNS as a whole.
The way I see it it’s about choosing one out of 2 tradeoffs: make it more opinionated and in the eyes of some less decentralized by integrating a KYT mechanism or keep it neutral and let services decide if and how they want to gate dirty UTXOs, the former comes with a potential for bad publicity as it might further the idea ICP is centralized, the latter comes with increased burden for devs who would have to do more work either by checking UTXOs themselves, or integrating with an external service.
The problem with the transparency argument is other chains are public by default, everyone can download all the chain’s state and verify it, regulators can keep track of all trades executed outside certain dApps, e.g Tornado cash, so the “taint” can be transferred to the exchanged tokens and if tokens come from service that obfuscate txs like mixers they are tainted regardless. On the IC things are different cause subnets don’t publish blocks and its up to individual dApps to make their state public and verifiable, with the current state of things even if the ckBTC canister were completely transparent, bad actors could convert tainted BTC to ckBTC, swap to ICP on a DEX, stake them in the NNS and washtrade the stolen funds by selling maturity, just to name an example.
Why were they against this? Because of the risks involved?
I’d think if anything KYT would make their lives easier from a legal perspective and give some plausible deniability.
The application can choose to implement their own ckBTC canister (xxBTC) if they so vehemently disagree, and applications can choose how they wish to proceed.
Something tells me the majority of applications and the majority of users will choose to use ckBTC though because of it’s redeemability on centralized exchanges.
“This is completely unnecessary. Because ICP itself can also be tainted, not just BTC.”
Agree fundamentally with this.
Yes, that’s right David, I believe it does. ICRC-1 can become tainted at any point, hence why KYT should be implemented by dapps themselves.
Hmm. It does not appear there is a universal solution to the problem of tainted coins. @Maxfinity and @Zane identify the wash trading example which is a good consideration and is what I was trying to convey to @bob11 but don’t think I articulated it well.
Example - Someone with tainted BTC swaps for ICP, and then ICP is swapped for ckBTC, and then ckBTC is unwrapped for untainted BTC.
That said, I would still be in favor of implementing a KYT canister wherever possible for ckBTC. I think we should make it harder for folks with tainted BTC to transact, and this adding this layer would certainly add an obstacle. The regulators are coming down hard on projects now and I think we should not be taking risks that are too big, especially considering the IC is in a weaker position right now.
This isn’t really a philosophical debate because as many have pointed out ckBTC is just one instance of wrapped bitcoin on the IC. Someone else can implement a non-KYT version of ckBTC. It really doesn’t matter.
The IC should offer people options and people can opt in given their risk profile.
Maybe the foundation offers ckBTC (KYT enabled) with 72 confirmations and ckBTC (no KYT) with 6 confirmations. Everyone is happy.
Regardless of how this turns out, it is obvious to me that the KYT canister is a service that will be used by many other services on the IC and this entire exercise will be super valuable for the ecosystem.
I’m not sure why this issue is worth discussing.
If ckBTC needs KYC, then I’d rather it never launch.
So far, most of the businesses that require KYC still only involve fiat currencies or payments.
Cryptocurrencies have been around for over a decade, and no mainstream country has laws that require KYC within a cryptocurrency system, unless you think IC is just an Amazon system!
Additional explanation.
Indeed KYT is different from KYC. My understanding is that KYT is more broad-based and its cornerstone is KYC or blacklisting, which in any case should not be mentioned on the chain for these features. That should be the domain of the off-chain service to deal with.
If my understanding was wrong, I retract my comment and apologize for that!
Would you please clarify your intended message? You referred to KYC several times, but this thread is about KYT compliance. Those are different topics. Did you mean KYT?
I am not a big fan of this KYT thing but it’s certainly different from KYC. There is no KYC involved.
Perhaps should launch and promote your own wrapped BTC without KYT.
I am very curious who and how people define tainted btc and also if we should trust those entities and criterias since this subject is very complex.
I would stay away from those shady undeterministic responsabilities.
Exactly
Wait, so you think we should have a debate about centralizing the ‘World Computer’?
Are we going to have this conversation every time some petty tyrant threatens regulation?
Censorship resistance, privacy, security, and decentralization should be core principles of the IC. Indeed, I thought they were.
When you find yourself contemplating an action that would undermine your principles do you seek to rationalize it or to reframe the issue?
Thank you Woodley for the inspirations
Or the NNS could let somebody else build the CKBTC ledger. and other canisters
No matter what we do with it, the risk is always in space and time looking for a moment to take advantage of the situation.
So "somebody else’ may be SNS1 communities or dedicated communities, canisters clusters, etc, to guard against , transfer , hedge off and even defuse risk with decentralized agents, governance, disposal of non-performing assetsand and many others!
Because we are a community of interests and even destiny
Maybe somthing like in some way
Best wishes!
The problem is that the coins which are added into ckBtc canister has to be pure (no illegal activities related to that coin)
There are a lot of analysis involved to get the relevant information whether a btc is tainted or not.
Req 1: all btc retrieved from ckbtc canister shall be able to be selled in cex as well as dex.
Possible solution
-
buying btc and adding it in the ckBTC canister are handled by the nns. It is resposnsible to provide sufficient buffer in form of btc in the ckBTC canister. But a user has to buy it from the nns.
-
adding btc to ckBTC would involve more cumbersome checks which need to be performed in similar fashion as already done by DEXes. Maybe some kind of whitelist of allowed sources can be used to add btc into ckBTC.
For example, if I buy btc from binance and sent it to my btc wallet and change it with ckBTC it should allow the transaction to happen. If it is from other source the btc will be added in my wallet but the ckBTc should not allow me to perform the exchange (btc with ckbtc). Whitelist are handeled by the NNS. -
All in all if btc are alllowed to be added to ckBTC then the same procedures have to be applied as already done by DEXes (only in a decentralized manner)
-
using some kind of whitelistings to restrict the source from which btc can be added into ckBTC
Thank you all for engaging in this critical discussion on how to move forward with ckBTC! To reiterate, here is a quick summary:
- Opportunity: ckBTC has the potential to greatly expand Bitcoin’s functionality by enabling fast and inexpensive BTC transactions on the Internet Computer and be a killer application for the Internet Computer.
- Concern: without some form of Know Your Transaction (KYT) checks, there is a risk of users unknowingly receiving “tainted” bitcoin that is not sellable on CEXs, rendering ckBTC effectively unusable for many users.
The high-level solution: As mentioned in my initial forum post and based on the multiple discussions we’ve been having with KYT providers and community members, a possible solution would be that ckBTC transactions interacting with the bitcoin network (ckBTC->BTC & BTC->ckBTC)) are first evaluated by one or more KYT providers in a decentralized manner. Ideally, the APIs should be run by various members of the ICP ecosystem with which ckBTC integrates.
For clarity, the KYT process is different from KYC (Know Your Customer). A KYT check on transactions does not reveal the identity of the user. It only tracks whether the bitcoin sent to the ckBTC canister has previously been associated with illicit activities.
KYT checks could be integrated into the ckBTC process as such:
Issuing
Redeeming
The goal is to mitigate the risks “tainted” bitcoin poses to users in a way that both avoids any further delay in the completion of the ckBTC launch in the short term, and in long term maintains a decentralized process of issuing and redeeming ckBTC. Discussions with Toniq Labs, other members of the ICP ecosystem, legal teams and various KYT providers are in progress.
In the short term, we are proposing that the NNS controlled ckBTC may rely on a single KYT provider. In the long-term, having multiple KYT providers will ensure higher levels of decentralization. Bob Bodily from Toniq Labs has already taken the initiative to explore solutions — hopefully more ICP community members will follow suit.
To ensure sustainability of the approach, the ckBTC canister would use transaction fees to pay KYT providers for their services, and the parameters of these services would be decided via NNS votes. Anyone in the ICP Community interested in actively supporting this KYT initiative is more than welcome to do so.
And as ckBTC lives in a canister and uses the underlying native Bitcoin integration APIs, anyone can implement their own version of ckBTC and deploy it on the Internet Computer – the code is open source.
As a last thought: laying out the foundation of such a KYT process now could prove to be highly valuable in the context of all ERC-20 tokens related to the upcoming Ethereum integration.
The crypto world shouldn’t trust an entity that works for the fiat slave system. We should find another solution to this artificial problem.
Completely unrelated question :
When is monero integration?
Is there any problem with making this an optional and stand alone service that people can plug into, to allow the best of both world?
Could even provide a “Certification” or something for people who use it if it quells consumer worries
Is there any reason this would not be a good approach?
@Jan
What if there is disagreement between KYT providers ?
Does American ones always win ? But China has more people, so Chinese ones should win right ?
What if someone sends a bitcoin to the ckBTC minter and then, a few hours after, this bitcoin is marked as tainted afterwards ? This solution is then at the very least useless.
With those concerns about Occidental political matter, this is feeling more and more like :
Internet Computer = Centralized American Computer.
(BTW there is two time the same diagram @Jan )
The ckBTC canister is open source. You or anyone else can modify it and roll your own with a different KYT (or no KYT at all).
The IC is still decentralized, but DFINITY is the central authority that created the ckBTC canister and open sourced it, so they have an incentive for users & investors in this new Bitcoin integration to feel safe in holding and using BTC on the IC, without the worry that their BTC will be labeled “tainted” and confiscated.
If people in other countries don’t like the KYT that’s implemented they’re free to roll their own no-KYT natively integrated BTC on the IC.
Both KYT & no-KYT can exist on the IC, I don’t see the conflict.