Direct Integration with Bitcoin

Then keep far away from it. Everyone here this is a good example as to why the dev forums needs to be moved on chain and an internet identity should be required for log. This guys apart of the same group of people that literally troll this forum. The devs here can’t even tell and then take their responses seriously. Literally do not waste your time with these people.

3 Likes

If ICP is a “shitcoin” that “let veryone [sic] loss [sic] 99% of their money”, then why are you so anxious about when a new technical feature will be released, especially since “it is everyone’s duty” to “keep far away” from this investment? I’m having trouble finding some basic consistency in your logic here.

As for those stupid enough to buy a pre-launch startup at a $300+ billion valuation with nowhere to go but down, I can only comment that they are well deserved recipients of the financial Darwin Award. Even at its currently depressed price of about $4, ICP still has an implied valuation of nearly $2 billion - a double unicorn, if you will. Keep in mind that we are in a bear market deep into a crypto winter with a rampant contagion of insolvency spreading across the entire crypto industry. Combine this with the fact that the IC has not even launched its SNS ecosystem yet, which is where its entire recurring revenue base (i.e., burned ICP) will ultimately come from. In this context, one could argue that a $2 billion valuation is still quite optimistic with a lot of potential downside.

7 Likes

Your comment I originally replied to in literally complaining about the development time of a feature being released when they the devs state it’s done when it’s done.

This coin is the most criticized coin to exist post launch day. Your criticisms aren’t even real criticisms you’re just complaining that a feature that has never been done before hasn’t been released yet and claim it’s never going to release. If you really think that why even pay attention and waste your time on this project at all?

It’s pretty funny outing you people out.

@Inch_Deen As a moderator of the forum, I ask you please change your tone. In particular:

  1. Focus on the subject at hand. Most of your comments are not about about the BTC integration or threshold ECDSA.

  2. Statements like:

you will delay again and gain to increase stable limit from 48 to 64, then to 80, 96, 112…
It won’t come out finally.
This comments implies that the BTC integration team is just pointlessly (perhaps even maliciously) looking for excuses. Instead of doing honest Research & Development as they work. I think that is unfair…

No need to delete your earlier comments (I have certainly said my fair share of nonsense on the internet, so I cannot cast stones), but can you please elevate your tones for future conversation?

9 Likes

Maybe my writing was vague and fuzzy, but I think there may be a miscommunication

I asked when it comes out?

To be fair, @dieter.sommer answered the exact question. What more were you looking for?

Your team delay again and again.

The team is doing research and development. They post updates on what they find, whether it be security, performance or other issues. I think it’s worth reiterating that what they are doing has NEVER been done. It is a lot of testing and experimenting. Expectations need to be aligned.

Waste customers? Don’t chart communities.

Not sure what this means, maybe you can clarify.

Let people only say good words to ur team? I don’t care!!!

I am not saying that people should only say positive things. I am saying that people should only be respectful. There is plenty of criticism and questions not just for the team, but also amongst community members, and I just ask that it be respectful and reasonable.

I hope that makes sense.

11 Likes

Is buying icp at $45 because of some larper on a basket weaving board just as bad as buying the launch? Say it ain’t so

The recent progress update seems to have created quite some discussion of one form or the other. Thank you, @diegop, for having calmed down some of the voices. :slight_smile:

I would fully agree that the forum is not the place for comments of the style and tone of some recent examples see in this topic. There are other places for polemic like this, e.g., various Telegram groups. The forum is reserved for technical, strategy, and other relevant discussions related the topic, but not polemic comments.

The teams working on Bitcoin and threshold ECDSA are working their a**es off to get this feature out to the public. As most here know, it is just a little complex and thus requires some issues to be solved here and there. We have been discussing the complexities and challenges of the Bitcoin part of the integration. Please have a look at the threshold ECDSA protocol we are implementing, that’s way beyond what any other blockchain project is even daring to touch. And there are challenges that need to be overcome here and there. So I hope this can also make clear to the critics here that this is exploratory work that may lead to challenges.

The most recent piece of work regarding threshold ECDSA is actually a request by the community for further strengthening its security by implementing IDKG key rotation, which is the only remaining blocker there.

The recent update mentioned that things are tight for an end-of-month release. End of November has been the goal since quite some time. Let me give you the details of our plan of how we can make the end-of-month release happen.

  • Nov 14: Hotfix release implementing the increase of stable storage per canister to 48 GB.
  • Nov 18: Have Bitcoin Mainnet canister working on a small subnet for now (manual install, not through NNS) to test the 48 GB limit and operation of the canister with the full storage amount for Mainnet.
  • Nov 21: Hotfix release for IDKG key rotation for threshold ECDSA.
  • Nov 23: All remaining changes for threshold ECDSA are included in the weekly release cut.
  • Week of Nov 28:
    • Rollout of IDKG key rotation.
    • Install BTC Mainnet canister via NNS proposal
    • Upload BTC Mainnet state to canister
    • Create threshold ECDSA production key on a large subnet
    • Create a new app subnet with a high replication factor (~34 nodes) and re-share threshold ECDSA key to this subnet
  • Have a party

As you can see, everything is on a critical path to get the feature done, that’s why we mentioned the following:

We hope that the above can convince most of you that we do have a very clear plan for a rollout of the feature by end of the month, which can work out if there are no new challenges. If there are, it may add a delay, but no one can tell right now whether this will be the case. Let’s hope for everything going smoothly and we all getting a shiny new feature for the IC!

51 Likes

Thank you, @dieter.sommer for the updates.

Like I have mentioned in the past, it is far more important to have both BTC-Integration and T-ECSDA CORRECT RATHER than ON-TIME. Schedules are given by men/women. They can be broken.

Broken trust (of code not working, buggy) is not easy to recover; especially with extremely shiny features.

We are in the last lap; but to land this thing will take patience & perseverance. My only request is : don’t listen to noise.

9 Likes

The technical level and scope of work that is being performed by the teams working on these projects is something I could only dream of fully understanding.
Thankfully there is an amazing team working hard on these projects and after implementation you can all enjoy a party for the hard work and dedication to the project that you so much deserve.
Rooting for you all & so sorry that you have to endure negativity along the way, but I guess that is par for the course when you’re a brilliant team of innovators. Thank you and rooting for you.

9 Likes

I’m looking forward to this part :grin:

I also want to again mention that what we’re planning to release end of this month is really developer facing: it gives canister developers the APIs they need to build dapps that work with bitcoin / ECDSA. This is not directly user facing. So while I absolutely think this is going to be a big deal for the IC, I expect more of a slow and steady growth of cool new IC dapps that use BTC/ECDSA than a sudden big bang.

DFINITY is building ckBTC (the “wrapped” BTC, but wrapped by a canister), building on the native BTC integration. This will not launch this month but later, but that will be something that end users can actually use for fast & cheap BTC transactions. Note that next week there is a public DFINITY Global R&D meeting that you all can join (register here) where we will give a demo of the progress on ckBTC.

17 Likes

We agree to all of that and it’s a pleasure to see that people understand the importance of this!

Security always comes first for features that wholly depend on security, like the Bitcoin integration. That’s why some things have taken us longer. But now we are in the final lap and will be able to release shortly!

Thanks everybody for their patience. You won’t be disappointed with what you will be able to do with this feature soon!

14 Likes

Thank you for the updates

2 Likes

Thanks so much for the frequent updates. I believe the community doesn’t mind delays provided we are kept in the loop. We appreciate you guys working so hard!

7 Likes

Hi, I have seen a paper you helped edit that said that ICOracle token (trading on the ic.lighthouse dex) will be needed for the Bitcoin smart contracts. Is this true or false.

Thanks for the updates Dieter!

Given the new index and the multiplier effect of that on the memory used, how long do you anticipate the 48GB will be able to hold the Bitcoin state until stable memory limits will need to be bumped again?

Also, instead of holding all of the state in a single canister and scaling vertically against hardware limitations, why not shard it horizontally? Imagining we get the new composite queries feature sooner rather than later and the Bitcoin integration is on its own subnet, wouldn’t this both help work around some of the current memory limitations and also improve the load scalability of the Bitcoin integration since the request load isn’t all then hitting a single canister?

We’ve now gone from having just 8GB of stable memory for over a year to then 32GB and now 48GB pretty quickly, which is exciting but also makes me wonder if using the full 32GB and 48GB has been tested thoroughly to ensure there isn’t much performance degradation.

Back in April, I asked,

What makes the team feel confident that vertically scaling the Bitcoin integration within a single canister is still the right long-term architectural decision?

7 Likes

Do you happen to know if we have to do anything special in our code to take advantage of 32GB or is it just included without any changes. Currently using mo:base/HashMap

You would need to use stable memory directly, so ExperimentalStableMemory | Internet Computer Home. If you have more questions I think Motoko stable memory in 2022 would be a great place to ask.

3 Likes

That’s a great question. We thought it was the right way to go for now. Scaling out to multiple canisters has advantages (more memory, can run concurrently) and disadvantages (clearly more complex to deal with multiple canisters). So we start with the simpler approach, and can always transition to a multi-canister approach in the future.

Note that the UTXO set doesn’t grow super quickly Blockchain.com | Charts - Unspent Transaction Outputs. In the last 3 years, it grew from 64M UTXOs to 85M, and we plan to grow the stable memory further, so I don’t think the single canister approach will be a problem any time soon, if ever.

13 Likes