Direct Integration with Bitcoin

I feel like the honeypots created by canisters are much larger than you would find by breaking out of the Wasm sandbox in most web apps (the web app is just the frontend, not the actual server where a bank account is managed). And each application (tab) in the browser has a Wasm sandbox, and that sandbox is also sandboxed within its own process. We’re pointing out that the IC does not meet the standard of the browser. If all of your tabs and domains shared the same process, that would be more equivalent.

It’s also only been a few months since the value inside of canisters started accruing, so not much time to feel too comfortable.

I think it comes down to this: there is an obvious vulnerability with an obvious solution, and we should make implementing that solution a priority.

9 Likes

I’ve voted no on this proposal mostly to make a point about security. If there is an obvious vulnerability that could lead to catastrophe, and an obvious solution, I think the priority should be to patch that vulnerability.

I would like to see canister sandboxing per process before deploying these features.

The same sentiment is reflected in this proposal: Enable Canisters to Hold ICP - #75 by lastmjs

10 Likes

I think that is a very commendable and engaging way to show your classic well-earned reputation for clarity of thought

5 Likes

I am bitcoin hodler from 2013 and very early supporter of dfinity since 2018 i truly support them. My Vote is YES

3 Likes

:trumpet: :trumpet: Thanks for such ringing endorsement!

1 Like

It nearly did make it it’s post. (“An inadvertent community driven bug hunting bounty program for IC”). I will articulate why I did not make it it’s own post with all the rationale here (as opposed to a provocative new post).

At first, an free airdrop doesn’t really cost end users any real money. As the NFTs begin to percolate the eco-system, people begin to pay real currency for acquiring NFTs. For example, i got a free nft (starverse) for my participation on dscvr.one. At the beginning, on the entrepot.app, the lowest price of one of those nfts was around 0.8 icp. Currently the lowest price is 1.89. Doubling of the price from nothing. This begins to cause a sense of entitlement (“it’s mine…I own it”) for the average end-user. Imagine if they log into the account one fine day and they don’t see that NFT. This causes anger, fury etc. They will begin to blame someone else (nobody buys the argument…“but it was beta”). They have lost something of value.

All participants do understand that crypto is inherently risky. But they also expect that reasonable protection be afforded to them on any platform. An ICAntagonist can make significant noise. i.e. " oh that dfinity foundation…200 cryptographers…and they FORGOT to put in basic sandboxing that WE have known for years…". Unfortunately logic (the fact that we have it in the roadmap) cross raw emotion and logic, in that case, has no chance. It can cause a catastrophic cascade with the right shills.

The reason that my articulation is here as opposed to top level is that most people will not bother to read a post 50 levels buried. But concerned discerning teams will… and hopefully take action as appropriate.

2 Likes

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