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.
6 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
For the exchange, seems Tacen is building something similar.
I agree with @Maxfinity on this one.
I strongly believe that introducing KYT is an horrible path to take.
Furthermore : you are concerned about mostly US law @Jan . US is not the entire world. Crypto is mostly about decentralization among other thing.
If in their crazyness the US is marking all Russian’s transactions as illegal. Are you going to enforce this ? And if next it’s China that is targeted by the US, are you going to do the same ?
I’m pretty sure there is a ton of people that consider the US as terrorists because of all their bombing all around the world in the past century. Maybe then we should consider BTC transactions from the US as tainted as well ? Why Americans should be given a higher status here at the protocol level of this feature ?
BTC doesn’t care, this is why it’s the most trusted protocol. Going down this dangerous road is surely going to kill the awesome opportunities that this feature is giving us. First for BTC maxis and then for the rest of the world.
8 Likes
Oh and for the record, the argument “this is fine, it’s almost decentralized” is bogus. If your shiny “decentralized” system is gated by a centralized authority, well then, what does it make of your system ?
2 Likes
Unfortunately I don’t think what Max is hoping for is technically possible.
I believe the only reason the foundation is considering this is because the architecture is such that tainted BTC can be transferred between users during the wrap / unwrap process.
That means if you send BTC to convert to ckBTC and then convert it back to BTC you may end up with tainted BTC. And then Coinbase will confiscate it from you if you send it there.
We do not want our users getting their BTC confiscated.
1 Like
For starters I largely agree with CoolPineappl18’s stance here. This feels like an issue way above the protocol level. Effectively, ckBTC is a service living on top of the IC… and who exactly controls ckBTC right now? Is it the NNS or the Foundation?
Personally, I see merit in having a version of the ckBTC canister which implements KYT and I myself would be most comfortable using that version. But, regardless of the decision made here anyone can deploy another version of the ckBTC canister with their own functionality, right?
Provided someone can always ship another modified version and the existing ckBTC canister is controlled by the foundation, I support implementing KYT into the existing ckBTC canister. Now, if thats the path we end up taking I think it would go a long way if the KYT providers were elected. Either through a market process, nns vote, something…
7 Likes
This is 100% correct.
I believe there’s another version called icBTC. If you want you can go ahead and use that instead of ckBTC and risk getting your funds confiscated, but avoid KYT. Totally your call.
1 Like
If the Russians control the IC, the Americans would complain that somehow Russians are not competent due to the number of oligarchs in that country.
If the Americans control the IC, the Russians would complain that Americans are flagging their transactions at high rate to avoid competition. And also the system of oligarchy is well alive in the US.
The solution might be to let the Chinese dictate the flow of transactions; if we are talking about flagged accounts.
However being African, I’d like to propose that we as Africans can dictate the terms of the flagged accounts; since Africa is well developed technologically in a decentralized manner. Africa is decentralized as the Western part Africa have their own developed system of governance, the Southern Africa region, East Africa region and North Africa region have their own developed systems too.
What’s lacking is how to convince the world that those regions as a unit or whole are capable of regulating the power of the IC. A solution can be for the IC development team to contact the African Union and request them to develop a regulatory body for the compliance of the ckbtc as this can result to being a human crisis issue. And then the African Union can set up a body that can regulate the ckBtc. Trust me when I say that the Africans are well capable of handling such a task. Africans are neutral and do not necessarily have bias to anyone. That would be a more stable solution that would last ages.
But if we are talking about speed, the only reasonable solution at the current time would be for the IC to comply with Chinese regulators about the flagged accounts.
Those are my thoughts and I do have more practical solutions but it is not the right time to implement them. Or like someone had commented earlier on, the focus on the flagged accounts should come in when they become a problem.
1 Like
@Jan I realized there might be another issue. Let’s say the wrapping process to ckBTC includes KYT. Ok, problem solved.
But wait. What if one of the DEX’s on the IC creates a BTC <> ckBTC swap that doesn’t included KYT.
For the record, this exact same topic has been discussed during the ICP.LAB DeFi version. All of the teams present were against implementing this IIRC. I’m tagging some of the people that were present so they can tune in if they like.
@brutoshi @Tbd @Maxfinity @witter @bitbruce @benji @AstroX @blockpunk @muharem
1 Like
Why don’t we look at what the wider ecosystem does and take inspiration from there. Just do what any other Defi protocol does that has pools.
My guess is they do nothing but are transparent, i.e. funds can be traced through the protocols. Does anyone have an overview of how all these Defi protocols handle it?
5 Likes
I agree, and have read through all of this wondering if what it means is that the ckBTC implementation has omitted to include this traceability, resulting in the concerns being voiced? Regulation is going to come, and go, and change depending on all manner of whims and objectives. If the architecture provides transparency and can be used to trace funds, then that’s all that’s needed. Adding in a blanket layer of regulation which enforces the entire IC community to be subject to regulations that probably only affect a specific subset of that community amounts to caretaking or even stewardship… make it transparent and leave it to Dapps and Dexes - individual DAOs - to consider if it’s important to them.
3 Likes
No this isn’t an issue. The ckBTC minter is the only place where ckBTC can be issued. A swap doesn’t matter because BTC is not going into the ckBTC BTC pool. The swap could be implicated, but the ckBTC minter is still clean.
1 Like