That’s the reality of software development, especially when a project does a lot of RnD and has to guarantee security of the system. To be honest as someone with a CS background I’m impressed how small the delays are.
5 Likes
I think no one disagrees with the amount of work that is needed to be done for a such a an innovative project… but I think that they should be more careful about announcing plans and roadmaps… at some point and after a year … you know how much is needed for a task and etc… at least for my experience working on demanded projects
2 Likes
Yes. Totally agree with you. Don’t know what the 200 ppl are doing? Delay delay and delay again, don’t know what they are doing, @dominicwilliams even have time to complain other projects all the time!!!
1 Like
@Mor First off, are you aware with how an engineering organization works? There are multiple projects and roadmaps going on simultaneously, and Bitcoin just so happens to be one of them, albeit a very important project.
Any one of these projects being rushed and deployed prematurely could introduce a bug or worse a security vulnerability, which would kill the reputation of the IC. I’d rather the DFINITY engineering team go a couple months over than deliver a dud any day.
This happens all the time in software, and to this point DFINITY has delivered on every major milestone. If they’ve delayed, they post status updates and are transparent about it.
The Bitcoin Integration was supposed to be delivered last quarter, but looks like it’ll be delayed till next quarter, big whoop.
@daijianlin What is so important that you can’t wait a quarter for DFINITY to deliver a pivotal feature that has is expected to work flawlessly? What “delay delay delay” are you talking about, it’s only been one delay thus far? Have you ever worked as a software engineer?
This stuff happens all the time from startups to Google/Amazon…be patient and go build something on the Internet Computer…the Bitcoin Integration will be ready for you when you finish your app.
6 Likes
Yes, I know. I have my own startup company. This is why I am asking. I am not complaining about the amount of work, I am highlighting the fact that the announcements are off the charts. Titanium was announced on twitter that was finished few days ago when it was already finished on februray… Not so good marketing… Just hoping on better planning. That’s all. No need to be defensive, I think some criticism could be productive.
2 Likes
Totally agree with you that the marketing got ahead of itself, but the teeth of my response was directed at this comment of yours in the quote above. It’s a bit of a stretch in my opinion.
Just my thoughts - you’re free to critique, and if you hit your milestones 100% of the time that’s great - just giving a perspective from the other 90% of software engineers out there that run into roadblocks or delays from time to time - this includes other projects like Bitcoin and Ethereum btw.
3 Likes
Probably, I was misunderstood. Sorry for that. The fault is never on the developers but on the management. This is what I wanted to highlight. Having such a great power of resources and minds and still giving a wrong picture outside. Have a nice day
1 Like
what is the difference this integration with bitcoin on avalanche ?Avalanche Bridge to Add Native Support for Bitcoin, Expanding Opportunities for BTC in Avalanche DeFi | by Avalanche | Avalanche | Mar, 2022 | Medium
2 Likes
I think it’s important for both to understand the other sides here, because both are correct.
Dfinity has a more traditional engineering/CS culture, where success comes from doing things correctly that don’t break.
Crypto has a more new age marketing/fomo culture, where success comes from doing things all the time to keep peoples attention.
Both need to accept these realities of the other, because the sweet spot lies right in the middle. Very few organizations can walk this line gracefully.
5 Likes
BTC direct integration on ICP using threshold ECDSA, meaning you can move your bitcoin natively on its blockchain. Avalanche Bridge cannot do this.
7 Likes
Hi everyone!
Just a quick update: Up until now, we said that we’d expose the Bitcoin integration API through a virtual canister facade (called the “Bitcoin canister”).
For technical reasons, we decided to make the API available through the (virtual) management canister instead.
This move doesn’t really change much for developers: The only change other than having to invoke the functions on the management canister is that the function names now have a bitcoin_ prefix.
I just wanted to mention that here in case you are surprised when reading (updated) material about the Bitcoin integration (such as the dedicated wiki page) and notice that the Bitcoin canister is no longer mentioned.
5 Likes
Thank for the update. when can we use UI to send & receive BTC on the ICP wallet?
1 Like
what is the difference this integration with bitcoin on avalanche
I did a scan of the technical overview of the new Avalanche Bridge just now.
There are quite a few differences I’ve observed:
-
Even with this new bridge, Avalanche smart contracts cannot natively hold Bitcoin. They have to go through the bridge to access BTC. This is in stark contrast with the IC, where canisters can natively hold Bitcoin. That means a canister can directly hold the private key to a Bitcoin address. There is no equivalent on Avalanche even after the launch of their bridge.
-
It’s quite expensive for IC canisters to directly transact with BTC. That’s why DFINITY is building a wrapped Bitcoin ledger, where canisters can instead transact with wrapped BTC on the IC with much much lower fees and finality times. This is similar with Avalanche, where after transferring BTC across the bridge, smart contracts can transact with the wrapped BTC to build DeFi applications. I don’t know which is faster or cheaper, but I’d be surprised if it wasn’t the IC.
-
In terms of implementation, the IC wrapped Bitcoin ledger is Just Another Canister, and can be made trustless like any other canister by removing its controllers. It inherits the security properties of the IC mainnet, and can easily be run on a more decentralized subnet with a larger number of nodes. Compare this with the new Avalanche bridge, which introduces a lot of additional complexity involving wardens and an Intel SGX enclave that are technically “off-chain” entities. It’s a beast, and more complexity means more opportunities for hacks and loopholes.
-
The Avalanche bridge only requires 3 out of 4 wardens to agree. The wardens are “trusted” operators, i.e. Ava Labs, Halborn, BwareLabs, and Avascan. Also, it’s not clear to me who runs the Intel SGX enclave, which is a single point of failure for the bridge, it seems. On the IC, the wrapped Bitcoin ledger runs on Just Another Subnet, which is operated by node providers around the world. And if you don’t want to go through the ledger, you can have your canisters directly hold BTC. You can pick.
-
On Avalanche, the bridge UI is hosted on Cloudflare. On IC, the NNS UI is hosted on the IC network. I assume the wrapped Bitcoin ledger, once complete, may also feature a UI hosted directly on the blockchain.
At the same time, most casual users don’t care about these differences. They just want to move their assets. Only when there’s a hack do they care…
20 Likes
thank you for your research.
Do you mean the NNS dapp?
I’m not aware of any plans to integrate Bitcoin support. However, I’m fairly certain that we will see crypto wallets with Bitcoin support on the IC before long.
Thanks, @jzxchiang, for looking into the Avalanche bridge and providing your findings! Much appreciated!
1 Like
Regarding the long discussion above triggered by @Mor 's comment, let me also provide some clarification from the side of DFINITY.
Indeed, we are being delayed with the Bitcoin feature (including threshold ECDSA) and I agree that communication on this could have been more transparent. As others have mentioned above, not all of our developers are working on this feature, but the Bitcoin feature has a handful of core developers assigned to the Bitcoin feature and the threshold ECDSA feature, who work on the related aspects on the different layers of the protocol stack. The features is pretty complicated overall as it cuts through all layers of the protocol stack and we have experienced some complications that took extra time.
As others have mentioned, we need to get this feature right the first time we launch it with Bitcoin mainnet being enabled. Getting something major wrong with this would be detrimental for the IC at large. Imagine a bug in the threshold ECDSA implementation that allows people to extract the value protected with the threshold ECDSA key.
Thus, we are taking all necessary steps to ensure that our code is correct and sufficiently tested and reviewd and run with Bitcoin testnet for a sufficient amount of time before we launch it on mainnet. We are doing both internal and external security reviews by specialized companies to increase the assurance of correctness of the code.
All that said, I agree that communication could have been improved related to the delays, that’s maybe something for me to take as feedback. But you can be assured that the Bitcoin integration team is working very hard to get this working and we are making pretty good progress.
Thanks to everybody who has contributed to this discussion and contributing their view on the reality of software engineering. The Bitcoin and threshold ECDSA features are indeed very innovative, complex, and large features that have had lots of unknowns that could (and did) cause delays in the engineering process.
13 Likes
Progress update
We got the Bitcoin feature working end-to-end with the full IC stack integration, i.e., all the shortcuts have been removed. The Bitcoin functionality has been moved from a canister into the replica. In this process we have experienced some unexpected problems w.r.t. performance of the adapter and associated high latency for block requests. Those have partially been resolved, but still cause some extra unexpected engineering efforts on our side to fully address. Our team has done a great job so far addressing the issues and we expect the remaining difficulties with the Adapter integration to be fixed shortly. Many thanks to the engineers Rosti, @0x5279616e, and @ielashi for their collaborative effort on chasing down the issues.
In parallel, we have been working on a stable data structure, a StableBTreeMap, that allows to store the Bitcoin UTXOs in stable memory and have the data structure manage stable memory transparently. Thanks to @ielashi for his tremendous efforts on getting this part of the work done (besides the other aspects of the project he is working on). The next steps here are to finalize this data structure and enable the BTC functionality to use it for representing the Bitcoin UTXOs in stable memory.
The complications mentioned above are typical things you see on a project of the complexity and scale of the Bitcoin feature. Considering the complexity of the project, it is practically impossible to give a solid estimation upfront on a delivery timeline. So the learning for us here is to not announce concrete release timelines before we can be reasonably sure to meet them. This has been discussed and we removed concrete timelines from some of our future milestones to address this inherent uncertainty.
Let me thank our engineering team once more for their hard work and great progress in addressing issues and bringing the project forward toward completion!
25 Likes
In parallel, we have been working on a stable data structure, a StableBTreeMap, that allows to store the Bitcoin UTXOs in stable memory and have the data structure manage stable memory transparently.
Is this data structure implemented in Motoko or Rust, and will it be open sourced once it is complete?
(I work with Motoko, so it would be really really awesome if StableBTreeMap was written in Motoko.)
Stable variables are insufficient as they still face the 4 GB canister heap limit due to serialization. A data structure that stores its contents directly in stable memory and that can thus take advantage of the full 300 GB would be huge for Motoko developers.
2 Likes
It is in Rust as we implement the Bitcoin functionality in Rust. It will definitely be open sourced as there will be interesting use cases for stable data structures.
Agreed! Simple stable variables mean you need to manually do all your stable memory management. Stable data structures that abstract the management of stable memory solve this problem and let you use a regular data structure that handles the stable memory in the background.
I wonder, if we had 64-bit Wasm heap some time in the future, would developers still want to operate on stable data structures or just keep everything in the heap and move in and out of stable memory in the pre- and post-upgrade hooks (i.e., use stable memory just for upgrades)? Deterministic time slicing should make it possible to have long-running calls which would be the case for transferring large amounts of heap to stable memory and back before and after upgrades.
Do you have an opinion on this? Just thinking whether it would make sense to further pursue work on stable structures particularly also for Motoko, e.g., as part of the grants program. Thanks already now for an opinion on this from your side!
8 Likes