I know the IC is really secure besides it being incredibly fast. But hearing recent news about the Wormhole hack, just makes me nervous. What would happen to the trust vested in IC’s technology if any of these integration would result in 100s of millions of dollars of BTC being stolen due to some exploit found in the IC - BTC integration.
I understand it’s not a bridge, but an integration where you would have native Bitcoin wallets on the Bitcoin blockchain. Do we have a risk assessment on what the probability is of someone finding an exploit? What would they have to do in order to find one? Is Proof-of-Work still being used for transactions? Or is it IC canisters creating new Bitcoin blocks? Can someone help me reduce my ignorance?
If you write a crappy contract that lets users withdraw your btc from your canister without having rights to it then it is possible. I’d recommend not using a btc canister until it has been audited and blackholed or subjected to governance by a very strong dao.
As you already understand, this is a direct integration with Bitcoin network, which will allow developers to build canisters that would manage BTC wallets. This canister that is being implemented by DFINITY team will open the API (interface) to other developers, so they could build solution for direct manipulation in the BTC network.
I believe that there is very low risk in finding an exploit in in this canister as it’s being developed by top researchers/cryptographers. And in fact this will only open API for the rest to do the stuff - there will be no real value in this canister (I guess).
The fun part starts with developers. As @skilesare said - it’s up to the developers how secure their systems are.
In general, I think the risk is as high as there are wallets connected to particular canister that talks to the btc_api_canister - but only if that canister has rights to manipulate all the wallets it’s connected to.
Let’s assume that I have a crypto payment service (canister) where you can pay with BTC through IC for any goods. If the interface from the btc_api_canister that is available for me as a developer require that each user of my service must authenticate through this btc_api_canister, then there would be very limited risk.
Also as @skilesare said, a DAO controlled, open source canister would be very reassuring here.
I believe that good solution here would be to create another canister similar to Internet Identity one, where the connected BTC wallets are stored and that end user would authenticate through this canister and get delegation for any other canister that would like to perform any transaction on user’s behalf.
Is Proof-of-Work still being used for transactions? Or is it IC canisters creating new Bitcoin blocks?
The latest canister being build will manage BTC wallets on Bitcoin network, so usual BTC transactions will occur with a use of PoW and new blocks being created - yes you’ll still have to pay BTC tx fees. The magic here is that you’re going to be able to sign your transactions through IC network.
Thank you! This clarifies a lot. I wonder if a security exploit does happen due to bad code, we would not be able to “vote” our way out of it using the NNS. Since stolen funds have already left the IC, right?
I feel like we should have DFINITY write and maintain most of the code regarding how transactions are handled and signed. So developers would not have to write these critical parts themselves.
The Wormhole hack happened due to the fact that the developers used as deprecated (unsafe) Solana function which allowed it. Interesting part here is that the function got deprecated in Solana v1.8.0, and right now the latest version is 1.9.5 - they had a lot time to fix and deploy. In fact they uploaded the fix to the GitHub 2 weeks ago I think and haven’t deployed it since then. And here are the 2 high risk factors:
Deprecated code that is not being patched immediately by the developers. I think that we should build a crawler that checks all critical (public) canisters for usage of deprecated code, which should be run soon after new vulnerability is found in commonly used dependencies.
Using public git repositories for codebases that manage lots of value. In Wormhole case, if they upgraded the repository soon after the patch was made, then there would be no hack. But as we know they made a patch with all the details and let it remain public for such long time (this is probably when hacker found about that vulnerability) without actually pushing it to the codebase. It was clear “oh look, you can hack me if you can”.
So, this was clear developers’ fault - if it was managed by strong DAO - it wouldn’t probably happen. And certainly not if the code was frequently audited (even by bots for known vulnerabilities/deprecations).
In case of direct BTC integration canister, if a malicious actor sent BTC from one BTC wallet to another through this canister - it is irreversible. No way to roll this back.
And to be clear, this is ‘direct’ integration which means that no BTC leaves Bitcoin network and, IC is used only to manage a BTC ownership on Bitcoin network. Treat this as a new software/wallet that could manage your BTC on Bitcoin network.
The issue is that code commits are continually published to their public GitHub repo in real time, which includes bug fixes.
But new IC replica binaries are deployed once every couple weeks.
So there’s a lag between code being merged and code being deployed, which could present a window of opportunity for an exploit, which is exactly what happened here…
If 2/3 of the nodes in a subnet collude or get compromised, they could sign transactions to steal all the BTC for all addresses that subnet controls. With most current subnets having just 13 nodes, I don’t see the market trusting significant value to this 9/13 “multisig.” We should make sure all BTC Chain Keys are controlled by a large subnet, perhaps the NNS subnet with 40 nodes would be enough. Also, more transparency around node provider identities would help, as users currently have to trust the NNS voters have done sufficient diligence on ensuring two node providers aren’t really the same people. Lastly, setting aside some ICP as an insurance fund in case of hack/collusion could be worthwhile.
But a secondary risk is also the non-diversity of the geo location of those nodes. Most of the nodes are in the US and W. Europe. These two groups of nations have,historically, tied economic and military interests. Having nodes in other parts of the world is important from a survivability(i.e takedown notice) standpoint.
If a risk assessment has been done to counteract this assertion, it would be good to know.
Roughly speaking I would say it is safe (ignoring any potential smart contract errors) until the value of BTC exceeds the value of the ICP market cap. From earlier conversations with Dfinity, the BTC multisig appears tied to chainkey so it would require control of chainkey or a network majority to be able to move any BTC on the IC. would be good to get someone from Dfinity to confirm this again though.
Hi! I know my question is off-topic, and I apologise for that. I really don’t know where to ask, where I can find IC developers, for the development of a dapp. Any suggestion, would be much appreciated. Thanks.
quite frankly i think you are in the right place (dev forum)… but wrong post. I suggest making a post, describe your project or about yourself… something that may make people curious enough to reach out.
I am surprised the issue was not addressed after your post, and has not been addressed so far on this thread. I hope we will get some responses to your query.
In terms of architecture, threshold ECDSA will only be available on dedicated system subnets and any canister can use XNet calls to ask for a threshold ECDSA signature. Security has been a main driver behind this design. As the subnets are system subnets, we do not allow end-user canisters to run on them. This reduces the attack surface a lot.
Furthermore, the threshold ECDSA signing subnets will be large ones, similar to the NNS in terms of security. The first subnet that will offer threshold ECDSA signing will start out with 34 nodes initially, which is substantially larger than the 13 nodes of the application subnets. Hope this helps address the concerns you have voiced in your post.
I posted a response not long ago. Let me know if it didn’t fully answer your question or you have follow-up questions!
Adding to @dieter.sommer’s comment above, obviously we spent a lot of effort on making the integration as secure as possible.
While there is always some remaining risk, the bigger risk is that users will send Bitcoin to a canister that is not secure or even designed to steal Bitcoin, as other forum members have pointed out as well.
34 nodes is a good start. The more nodes we throw at that subnet the less the other concerns matter. I’d like to see it in the 100-200 range eventually.
Currently every major L1 bridge is essentially a two-thirds multisig.
Avalanche bridge is 3/4 multisig securing $5B assets.
Solana’s Wormhole bridge is a 13/19 multisig with $1B
So billions in value is already trusted to similar setups. But most bridge users IMO are DeFi degens seeking yield so I anticipate security and trust will become bigger concerns as the market matures.
We should strive to beat these competitors through more nodes, more transparency around node providers/sybil protection, and better UX.
I second this, however ultimately this requires creating a decentralized governance system that is trusted. Not a trivial task, we have tried for many millienia.
We plan to initially deploy one threshold ECDSA subnet with 34 nodes and increase its size gradually, roughly in lock-step with the NNS’ increase of subnet size. We think NNS-grade security is the way to go for the threshold ECDSA subnet. I agree that the security requirements grow with adoption of the functionality and the amount of assets secured by the threshold ECDSA key.