I think it is worrying to surface, but more so confirming, these things on a forum level completely in the open. It only takes one person to forward this in the wrong direction and then you have the avalanche started with antagonist shill to tackle in the future. Not to mention that you openly confirm where the security risks are, for someone with bad intentions will just go straight ahead to try to utilise. Some parts should not be surfaced/confirmed in this way I strongly believe.
3 Likes
Did you miss the community conversation yesterday on Bitcoin Integration with Thomas Locher (@THLO )?
Here it is:
4 Likes
Update: the motion passed!
2 Likes
A random question:
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.
2 Likes
Liquid democracy requires an informed citizenry. Security by obscurity is not true security.
4 Likes
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.
2 Likes
Oh wow, I didnāt know this was already on DFINITYās roadmap.
3 Likes
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.
2 Likes
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.
2 Likes
@jzxchiang, @integral_wizard
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.
16 Likes
These are the kinds of posts I love to read
4 Likes
Update: we have a new thread for security sandboxing. We hope this will pick up speed shortly with more concrete plans.
3 Likes
Thanks for the detailed response.
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.
9 Likes
Is there a current estimate for the integration of the above proposal? More at the end or the beginning of Q4? @diegop
And of course, as always with engineering deadlines: which yearās Q4 
4 Likes
Currently, I believe it is tracking for the end of Q4 2021.
@THLO @dieter.sommer please correct me above if wrong as you are closer to this.
1 Like
Oh, you 
3 Likes
Correct.
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.
2 Likes
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?
4 Likes