Came across a thread on X by Bitcoin Layers that has a security review of ckBTC. Here is the thread.
Link to the full write up. Hopefully Dfinity can provide some thoughts.
2 Likes
I am old enough to remember the promise that Bitcoin integration to IC would be a game changer for IC. As of today, after 1 year and half, there are 281 bitcoins on IC and we are learning today they may not be as safe as we were told they would be.
Is that the level of success Dfinity and DW were looking for?
I am not giving up on IC but it does not look that good anymore.
I expect the FUD screamers team to jump in but it will not change the reality of where IC stand now and that the future still only stand on promises and vision, not on real things.
2 Likes
I think they did a good job reviewing ckBTC. It may be surprising to see them say āhigh riskā for certain areas, but I think itās important to look at the methodology of bitcoin layers. They have clear rules defined on what they consider high risk. I personally think those rules are a bit too strict, because for example every single bitcoin layer they reviewed (other than lightning) has received a āhigh riskā rating in the custody category. However I do think they review the different layers fairly and hold each to the same standard.
Comparing with how they rated other projects, ICP/ckBTC received the same rating as Stacks, and most projects they reviewed were considered higher risk by them than ICP and stacks.
13 Likes
Manu how feasible is it for 10/28 node operators to collude? My understanding was that even if they wanted to, it would be next to impossible due to node shuffling.
We think itās very unlikely. Note that we dont automatically shuffle nodes between subnets, but the key is regularly reshared among the participants. So these 10 node providers would need to actively collude (while being identified and having signed a statement of good intent etc) or some hacker would need to manage to break into 10 of 28 node machines at the same time.
4 Likes
Sorry I meant key resharing not node shuffling. Thanks for clarifying.
Are there future features that might make it impossible even for collusion to take place. Perhaps VetKeys?
I made few comments on x and Iāll repeat them here:
-
Was any thought given to making the output script on the ckBTC utxo have a secondary emergency lifeline key like maybe a governance subnet Dapp that could via governance be used in an emergency to unlock the UTXOs if the pxxxx subnet was compromised or blown away?(This may increase risk in other areas like making an NNS governance takeover more likely).
-
When the value on one of these subnets gets super high, is there any plans or thoughts for a slashing scheme to keep nodes honest? At some $ value($1B? $10B? $100B?) can we expect a 28 node subnet with no slashing to stay secure without them having to put up some kind of additional collateral at risk? And how do we compensate them for that collateral?
6 Likes
At the growth pace that IC is adding bitcoins since 18 months, my calculation is that it will take 92.6 years before reaching $ 1B. Useless to talk about 10 and 100B.
This is the reality now and nothing indicate that this growth will change anytime soon.
So I wouldnāt care much about that for now if i were Dfinity.
2 Likes
No one is here for the current reality.
2 Likes
What I find interesting is that most of these L2s donāt use anywhere near as secure a protocol as threshold ECDSA. Itās really like comparing a space ship to a lifeboat.
5 Likes
Sooner or later, the reality will catch up. Until then, have fun and good luck!
Hi everyone, this is Janusz from the Bitcoin Layers team.
Firstly, I want to thank @Manu for acknowledging our intention to do these reviews fairly. We have a bias, but we review everything directly against our framework. If we make changes to this framework, we acknowledge it publicly.
We developed this framework in the open, and held numerous open discussions to gather community feedback prior to publishing it. Our bias is that Bitcoin L2s directly inherit security from Bitcoin, ensure anyone can contribute to the integrity of a two-way peg, and/or ensure that users have the option to retain sovereignty over their assets.
Thereās additional risks and nuances that are not directly covered in our assessments. As mentioned in the methodology page, this is a living document. We have been actively discussing ways to improve it, especially as we review more diverse protocol designs.
If you have feedback, the best way to provide it is via submitting an issue in our GitHub. Weāll address honest feedback. Our website is also free and open-source. Anyone is welcome to contribute to reviews.
Thanks,
Janusz
11 Likes
most recently I published the following tweet. it is more related to the displayed TVL of Bitcoin on ICP than the ckBTC implementation itself, but I think it fits best into this topic here.
when referring to the ārealā TVL it is very important to understand that BTC can be stored securely through different canisters on ICP which are completely unrelated to ckBTC.
by default the information about TVL of Bitcoin per canister is not available. I think it would be cool to define a standard which canisters can follow to expose such information to be used by 3rd party analytics tools like e.g. Bitcoin Layers. actually such standard about TVL could also be relevant for other assets (Ethereum, any ERC-20, Solana, ā¦)
any thoughts on that? maybe that can be discussed in the BTC on ICP working group (cc @bob11 @domwoe)
1 Like
Hi @marc0olo,
Great proposal, though not sure if it is best discussed in the BTC on ICP WG for two reasons:
- Most teams in the group leverage ckBTC
- As you mentioned, the scope should be bigger than BTC.
Probably best to start a new post in the forum (and maybe a draft).
One approach would be to expose the addresses a canister controls. We could use a convention like CAIP-2/10 to specify addresses across chains and even provide the derivation path such that itās verifiable that the canister indeed controls these addresses.
However, the approach becomes a bit less clear if funds are locked in smart contracts and are not directly controlled by an EOA.
2 Likes
Yeah this is interesting. I do like this idea. Increases TVL numbers and is accurate, in that there are many assets being controlled by the Internet Computer Protocol that should count as TVL.
The implementation here feels a bit complex, but I would like this information to show TVL growth of cross-chain assets on ICP.
In fact, this is probably my top number to watch with the Chain Fusion thesis. I think this is the number we care about most. Chain Fusion success = total TVL of all cross chain assets on ICP. So this number should be tracked and should be used to determine success of all chain fusion initiatives.
3 Likes
I will have a look at CAIP-2/10. indeed it should be verifiable through the canister. otherwise there is no evidence that the provided TVL is correct which would make the effort kind of meaningless 
same here. for that reason I propose to introduce that 
no draft yet, but I agree that we should discuss that in a separate post. I created one here:
1 Like