If this proposal will allow for the IC to make outbound connections to the Bitcoin network, can we leverage that same technology (however it’s implemented) to make outbound connections to arbitrary external services?
I’m guessing some kind of oracle will be part of this proposal’s implementation.
Not a random, but a good question. The answer is YES! Although not immediately available. One part of this integration is the network module that is added to the IC. This will be used for eth integration but also to do outside calls. This primer explain the integration in more detail: Integrating the Internet Computer and Bitcoin Networks | E001 - YouTube I also pasted a slide from that video overview that shows the added components.
I understand what you mean, but from where I stand I could not say what course of action to take even when given this knowledge (would you?), but those with ill intentions will just dive into and dig straight at the source where there also might be other security risks in the proximity to the surfaced one that has not been identified to utilise this as entry vectors as well. Where there are one security risk there might just be other ones lurking around. In some aspects, certainly when it comes to security risks, I don’t think the community as a whole is equipped to make a decision around this.
Everyone wants more information on IC-530. My suspicion is that HTTP calls are OK here because the messages being sent are signed, nonrepeatable, and a sure to be broadcast and included by anyone seeking financial award. I have some reservations that other kinds of http requests(say hitting an aws api) would have the same kinds of guarantees. I’m excited to hear more though in case they have cracked the determinism problem.
If I were a NFT buyer, putting down 188 icp for buying one NFT, I would like to make sure that my investment is secure. This information might make me insecure… therefore the concrete action that I take is NOT to spend 188 ICP.
What you see on the slide from the video posted above is a high-level overview of the Bitcoin integration architecture, including the networking part. As you already observed, the networking architecture is being built in a very general way so that it can serve multiple purposes besides the Bitcoin integration: Another crucial purpose here is a future Ethereum integration, and yet another one is allowing canisters to make http calls or do arbitrary networking. The idea here is to provide all of those functionalities with a single, unified architecture that is part of the IC protocol stack. Different protocols (BTC, ETH, http, TCP …) would share the bulk of the architecture components, e.g., at the networking level, and each receives their own Protocol Adapter. This way, we can keep the architecture highly modular yet powerful, and with an as-small-as-possible integration surface with the IC protocol stack.
There have been some security concerns voiced above regarding security. We do address relevant security concerns early on as an integral part of the architecture (“by design”) and don’t bolt it on afterwards. For example, we plan to sandbox code that is performing “dangerous” tasks like parsing of untrusted content in a highly confined sandbox such that, even if someone manages to mount something like a remote code execution attack by providing maliciously crafted networking responses (e.g., an attacker’s Bitcoin node we connect to), they will not be able to break out of the sandbox in the (very unlikely) case of success of their attack, thus will not be able to do any real damage, even if their RCE succeeds. Note that the code most susceptible to vulnerabilities is code for parsing untrusted content, that’s why we want to sandbox these code parts and isolate them for the remaining system.
Another discussion further above was the WASM execution sandboxing. As mentioned, we want to bring it on our roadmap, but we cannot give you a concrete timeline currently.
And please do not forget that our choice of language, Rust, on its own already helps reduce certain classes vulnerabilities at the implementation layer due to its inherent properties. That is, security is taken seriously on every level, end even without the abovementioned additional controls related to isolation, we are already well positioned because of our language choice, diligent engineering processes with code reviews, and other QA measures that are in place in our engineering process.
If the IC does in fact implement a networking layer that allows smart contracts to make arbitrary network calls in a distributed way, that would be a massive step forward. I don’t think any other blockchain natively supports that. AFAIK they all resort to an integration with some off-chain oracle solution like Chainlink.
However, the same is true for the threshold ECDSA feature. If the threshold ECDSA feature is ready around the end of the year, the launch will likely be moved to Q1 2022 to give us sufficient time for end-to-end testing.
Will the implementation of the BTC <> ICP proposal include the famous networking module that allows a canister to make external HTTP calls to arbitrary domains? Or will it be limited to the BTC network?
While the Bitcoin integration will lay the foundation for the functionality to make external HTTP calls, it is a separate piece of work.
Since it is an exciting feature, I hope that we will be able to work on it early next year!
If I were to phrase how the BTC bridge works - in non-ICP terms.
Note: I am not an expert on how ICP works and I simply assume that there is a set of validators assigned to a cannister that locks up stake in the native token (Please correct if wrong!!!)
A cannister runs a Bitcoin light client (a BTC-Relay) that allows it to verify that specific Bitcoin transactions are part of the main chain + some parsing functionality.
When a user wants to move BTC onto ICP, she deposits this to a address generated by the cannister.
This address is generated from a ECDSA public key that was in turn generated via an ECDSA threshold scheme.
The validators (?) of the cannister jointly control the public key. That is, only if e.g. 2/3 sign, the BTC can be moved.
Questions that arise:
How do you update the threshold signature scheme when the validator set changes?
Does the ECDSA threshold implementation suffer from the same issue as the one used in tBTC (i.e., one can only check how many signatures were made, but now who) or does this implement the improvement suggested by Gennaro & Goldfeller? And is the latter improvement already feasible in practice (I have not yet seen any implementation and would be grateful for a pointer!)
How are users protected from failures? Since there seems to be no collateral that will be used to reimburse users in case of failure, users must trust that 2/3 of the cannister validators are honest.
The challenge here is that the security model is different from the single-chain / ICP only setting. To attack ICP, validators must collude and risk losing their deposit. The value of the attack, however, is hard to measure: the ICP price would crash if a major attack happened, stake would be slashed etc. - so it is unclear how validators would measure the value of the attack.
In the case of a BTC bridge, the attack setting is different: the validators must only decide to steal the BTC. There is always a direct comparison to their stake in terms of e.g. USD value: the USD value of the total BTC locked in with the cannister deposit address - and the total value of the stake locked by the cannister’s validators in ICP tokens. The moment the BTC is worth more, validators are incentivized to steal.
Wondering if and how this is address - and if I have at all understood the bridge / cannister design correctly.
Thanks in advance and thanks for being patient with my lack of ICP knowledge.