It sounds like we need to do KYT.
1 Like
Or don’t do anything. Or better yet let developers build wrapped assets and they and users can assume the risk or not.
Remove the NNS from having to make any decision on KYT or KYC. Coolpineapple makes a very strong case why we shouldn’t. See thread: https://twitter.com/CoolPineapple18/status/1630932913352065025?t=NV_tOOKgVxQ2aoIi3E1GKw&s=19
6 Likes
this is a bad idea. CKBTC will be a Russian roulette . 0.01% chance the money doesn’t work.
ckBTC should only be seen as a mixer if the transaction history is not transparent. If the transaction history is publicly viewable, i.e. if minting/buring and ICRC-1 transfers are viewable and public then AML and KYC operators can always view this log if need be to trace BTC. Tornado Cash is fundamentally different because it is not a transparent service.
I think the solution is to not KYT (every service provider and exchange will have different requirements, and it just will make the chain look centralised), the solution is to make sure that the ckBTC is not acting as a mixer, which it isn’t if the transactions are transparent on the IC.
So why not implement a service on the IC to track Bitcoin transfers as ICRC-1 tokens and open source this to others. Then any service provider will be able to use the endpoint to determine if Bitcoin withdrawn from the minter originated from dirty bitcoins that came into the system. However, no gatekeeping would be necessary.
17 Likes
I agree. I think this KYT thing is a horrible idea and will definitely make the IC look very centralized which many people already think it is, and whether the perception is true or not is irrelevant. Both #BTC and ckBTC ledger are transparent so exchanges can use their chain analysis tools to track this stuff as you stated. No need to put the NNS in control of another thing.
7 Likes
The Bitcoin integration and ckBTC is already controlled by the NNS, so it’s the NNS DAO and NNS that could be held responsible if there is a regulatory crackdown.
I think it’s prudent to get ahead of this and put in place a KYT system, where the system itself is owned by a DAO and transparent to both regulators and ckBTC users.
I’d be in favor of this KYT software system to be decoupled from the protocol itself and to go through an SNS, allowing ckBTC users, dapps, and exchanges the opportunity to invest and have a say in the software and process by which “tainted” UTXOs are defined/identified.
4 Likes
This would be ideal. I do think ckBTC is fundamentally different to a centralized bridge that creates wrapped tokens. Provided authorities can properly trace tokens across chains I don’t see why authorities would treat the integration as a mixer when it is not. If you can clarify this point @Jan it would be helpful in thinking through the problem.
All that said, the thought of a DAO (the NNS) paying for a centralized service like Chainalysis KYT is kinda trippy and futuristic. Maybe that’s the future
Can someone provide an overview over how all the other Defi products on all other chains do it? Most of them must have the same problem. Whether you use an AMM, DEX, decentralized marketplace, provide liquidity, etc. it can always happen that you (or everyone) gets tainted coins out.
2 Likes
I would no nothing.
-
Are we here to do politics ? If the world is splitted in 2 and each parts would like to give a stain to others transaction would that be helpful ? I am not sure.
-
If someone steal a btc and it become stained and cant use it anymore, does that really help the person that got it stolen ?
-
BTC works well and they dont do anything right ?
-
We could still decide to implement it later, why such a hurry ?
Just my opinion.
2 Likes
Very interesting topic! In my view, staying as decentralized as possible must be key. However, I would closely monitor future regulatory developments in the industry so as to act accordingly and not risk being blacklisted and thus jeopardizing the long-term adoption of the project.
Max, while I agree with your point in theory, I think it may fail in practice. Getting every exchange and governing authority to understand that a “utxo changes into a transaction chain and when it gets back to a utxo it is actuall different owners” is going to be one hell of a practical challenge.
I don’t even think that icrc-1 has a hash that chains through it which we might get them to understand.(why didn’t we put that in the standard?)
If ICP becomes a monster and THE web 3 scaling layer, then maybe…but from my view here at ETHDenver “optimism is the new punk” so we still have a hell of a mountain to climb.
1 Like
Agree on the hash thing with ICRC-1 and am also advocating for lookup by hash.
3 Likes
This is completely unnecessary. Because ICP itself can also be tainted, not just BTC.
4 Likes
I don’t really see a problem with rejecting “tainted” BTC so it is never transacted with ckBTC. It seems reasonable to keep it out of the system on the inbound side so it isn’t a problem for someone else on the outbound side. The use of KYT doesn’t bother me based on the information discussed in this thread so far.
2 Likes
Aave and Liquity don’t do anything. I don’t know about the others but I’m not aware of any that attempt any filtering. If anyone knows of any large ones please say so.
So far it seems only one protocol, Tornado Cash, has had strong backlash from a major jurisdiction. It is specifically designed as a mixer. Other mixers have not seen significant backlash, and neither have to my knowledge other defi protocols designed primarily for other purposes so far. Monero, the main privacy-preserving coin, has not seen comparably large backlash either.
Centralized exchanges have this issue because they’re essentially private mixers. Assuming traceability of BTC->ckBTC->BTC, there shouldn’t be a problem. I agree with Max to focus on complete public transparency, even consider tools to make it easier.
7 Likes
Hey everyone, love the conversation that has been happening so far. I’m extremely involved in this and want to give my perspective:
At Toniq we’ve been building Bioniq for the past month. Bioniq is a BTC ordinals marketplace built on the Internet Computer. We’re building Bioniq as a native BTC application, meaning we won’t have ICP NFTs or ICP tokens available on the marketplace at all. ckBTC will be the native currency of the marketplace, and you will only be able to view/transact BTC ordinal NFTs on the marketplace. We are making fantastic progress, and if you haven’t seen the crazy traction around BTC ordinals, we’re really excited about the potential for Bioniq to bring a lot of positive attention to the Internet Computer.
In order for Bioniq to work we need a ckBTC solution, so I’ve been discussing with Dfinity over the past few weeks to try to come up with a workable solution that can be implemented quickly without sacrificing decentralization/security.
Over the past few weeks I’ve spent 20 hours on calls with Toniq AML legal counsel (Goodwin), compliance case management providers (Unit 21, Hummingbird, ComplyAdvantage), and KYT providers (Elliptic/Chainalysis) to try to come up with the best solution. The best solution in my mind (1) maintains decentralization as much as possible, (2) mitigates risk for all parties involved, and (3) is actionable and allows us to move quickly to a solution.
Just so everyone understands what I’m referring to, let me add a few definitions here:
KYT provider: a centralized service (like Chainalysis or Elliptic) to screen wallets/UTXOs for risky crypto assets. This can be called directly from a canister with an API key as the only centralized point.
KYT: know your transaction. Simply an API call to a KYT provider that returns a risk score associated with a particular UTXO or BTC wallet address.
Importantly, KYT has nothing to do with KYC. Users won’t have to provide any personally identifying information to interact with the ckBTC minter. In fact, the entire process (using a KYT setup) is still almost completely decentralized. There can be many KYT providers (decentralizing the KYT process) and these can be switched out as needed (further decentralizing the KYT process). The KYT piece is really isolated to the management and rotation of an API key.
So my final thoughts:
First, we absolutely need KYT as part of the ckBTC process in order to mitigate risks for everyone involved. Whether you are a dApp wanting to provide a frontend interface to wrap BTC to ckBTC, or you are a user that is interacting with the ckBTC canister, or you are part of the NNS that will be governing the ckBTC minter canister, adding KYT reduces risks for everyone involved.
Second, there aren’t really any additional risks by implementing KYT. You can always just get a new API key, new KYT provider, etc. These can even be added over time to further decentralize the KYT process. So we reduce risks for dApps, users, and the NNS by implementing KYT, and we don’t add any additional risks by adding KYT. The KYT process will be built to minimize the reliance on any single KYT API key or KYT provider.
Finally, on top of the ckBTC KYT process (which is absolutely needed) it is likely that Toniq will need to implement a KYT solution on our own frontend. Both pieces are needed based on the legal/AML/compliance conversations I’ve been having.
If you have questions, you can reply here, or DM me on Twitter (@BobBodily), or you can grab a time on my calendar here: Calendly - Robert Bodily. Thanks everyone.
9 Likes
Is this API key really a private key and the access control is signature-based and threshold ECDSA can be used? Just asking because if it was just a secret token that has to be shipped in the request then that would not work from a canister because a canister cannot reliably hold secrets.
A problem remaining with this approach could be that the risk score changes over time as new hacks and thefts become known to the KYT providers. Could this approach create an incentive to hackers to send their stolen funds directly (or as fast as possible) from the hacked source to the ckBTC canister? Then the KYT would not yet raise a flag and ckBTC would accept it.
Well, maybe not if we are waiting for 144 confirmations. Maybe the slowness is the solution. But still, there will be hacks that aren’t recognized and published in a day.
4 Likes
I believe it would be a secret token that has to be shipped in the request (standard Web2 API), but @Manu can confirm and discuss security risks here.
Risk score can definitely change over time, but this applies to anyone using KYT anywhere. Waiting for many confirmations can mitigate this (as you mentioned), but I acknowledge this isn’t a 100% perfect solution. Perhaps it is good enough for what we need right now though.
After giving it further thought, I believe introducing KYT for the ckBTC canister would provide an incredible use case on a dApp that is both decentralized and regulatory compliant (at least in the West). Our goal with the Internet Computer is to become the Crypto Cloud. That means having tools and services that are actually used and not just crushed by the regulators. This is all the more important now that regulatory activity is heating up.
Censorship resistance exists along a spectrum. dApps can either choose to be more or less censorship resistant and regulatory compliant depending on their desired use case. Lets say the NNS decides it wants ckBTC to comply with American regulators but not Russian or Chinese regulators requirements. That is a decision that the NNS can make. Each dApp can decide to make its own trade offs depending on the token-holders of that dApp. In the case of ckBTC, that means the ICP holders (NNS), but in the case of Openchat, that means the CHAT holders (SNS). I personally would love to see a fully on chain order book DEX that works like Coinbase and is both fully compliant in the US AND decentralized. My understanding is that this AML canister will be opensourced so other projects can use its code too.
As is clear, even bitcoin is not fully censorship resistant because if you send tainted bitcoin to a centralized exchange like Coinbase, Coinbase will confiscate the bitcoin and report you to the authorities. Given how ckBTC works, it seems that there is simply no technical way to avoid tainting all of ckBTC if even a small tainted portion enters the mix. It is also important to note that ckBTC is not the base layer - it is an application built on the NNS.
I urge everyone to think bigger. Imagine if we have applications on the Internet Computer that are used in the real world. It is an unrealistic fantasty to think crypto can be used in any major way without falling in line with at least some regulators.
AGAIN, I think this block in the road is another blessing in disguise. Just like the whole casino front end being blocked caused us to reconsider boundary node architecture, I believe this minor delay in rolling out ckBTC will create new real life opportunities to bring applications on the IC into regulatory compliance that can be used in other use cases.
The key here is that each DAO will be able to make its own decisions according to the tradeoffs. This is a no brainer trade-off I believe we should be excited to adopt.
9 Likes