Direct Integration with Bitcoin

Roadmap
443

It’s at least partially my fault that there have been few updates in the recent weeks as I have been usually doing them, but have been off for summer vacation for over 2 weeks. I should have still maintained the usual pace of updates to not leave this gap in information I guess.

@diegop already provided you with lots of valuable information regarding the status and reasoning behind it. Let me give you some more insights, with a bit more technical detail.

Threshold ECDSA
As Diego has already mentioned, one of the big items here is to increase our assurance of correctness of the implementation. We have already done one external round of code reviews with a world-leading code audit company. We are planning to do another round when the changes that we still want to implement are complete. This will be again with a top-notch external review firm. And of course we will be doing lots of testing on our own.
In addition to these assurance-related efforts, we still need to work on improving the performance of the implementation. We are currently running the system with the test key on a 13-node subnet. For the production key, we decided to start with a 34-node subnet for the security / decentralization we want to have. This has a major implication on performance, i.e., it will be quite a bit slower there. In order to reach, what we think is an acceptable level of performance, we need to put some more thinking and engineering effort into getting good-enough performance on such larger subnet.

Bitcoin
You were asking about the tasks that remain to be done for the Bitcoin integration part. What Diego means with security improvements are some very specific protections mostly agains very powerful adversaries. One could consider most of the possible attacks to be theoretical, but we are paranoid and want those to not be possible at all.
One of the larger items in our backlog is one huge performance improvement. I need to give some details to explain this: The system tracks UTXOs in a UTXO set, but it provides the capability to resolve forks. Thus, it needs to keep a number of blocks that are not yet absorbed into the UTXO set as they might be on the wrong branch of a fork. Only once we are sufficiently sure that a block is not in a wrong branch of a fork, e.g., after hours worth of blocks, a block gets “absorbed” into the UTXO set by adding the UTXOs its transactions create and removing the ones they consume from our UTXO set. Queries thus need to query the UTXO set and all “pending” blocks towards the chain tip of the Bitcoin blockchain which may be dozens depending on how conservative we are. This is currently not implemented very efficiently for the Testnet release and needs to be sped up to have acceptable performance for the Bitcoin Mainnet release.

Also, as has been mentioned multiple times in this and other forum topics, projects like the Bitcoin integration are really hard to plan precisely because it’s all new and has never been done before. Clearly, it might be possible to plan more thoroughly and spend more energy on this, but this would partially contradict the idea of an agile software process which we follow at DFINITY quite rigorously. And in an agile process, you cannot give planning figures like in a waterfall process, particularly when the work is as exploratory as for Bitcoin and threshold ECDSA.

Also, we expect some minor bug reports from the community related to our Bitcoin Testnet operation which we will fix as they come in.

Hope this explains a bit better what is happening on the technical front.

19 Likes
444

Hi there, if you find a bug you can:

  1. Post here or
  2. DM @dieter.sommer or @Manu if you think it is sensitive.

Did that answer your question or did I misunderstand?

445

You can be assured that any potential attack vector WILL BE exploited by powerful adversaries to the extent that it is exploitable. In this game, “only the paranoid survive”.

So please, please take the time to make it correct.

7 Likes
446

I think we have a healthy level of paranoia here at DFINITY! :slight_smile:

9 Likes
447

Keep up the good work ladies & gentlemen/Dfinity team members…what you’re doing is very complex, and though you are racing to be first, you also understand that it has to be tight before its released and ready to be put into real life action, there is alot on the line.

8 Likes
448

Based on a new update in the tECDSA thread, is it correct to not expect the full release before November 2022?

11 Likes
449

我According to the productivity of developers in the past, I think it will be longer today next year?

450

Roughly, as of a current estimation, but we run an agile process, so don’t take this as firm timeline. We do actually not provide a concrete timeline for GA, having learned from previous experiences.
See here for the scope of the GA release, it will include also the ckBTC canister.
As mentioned above and in the t-ECDSA topic you are referencing, there are a couple of things we need to get done before we can make a GA release. If we see a way to release earlier we will of course do so. It’s also in our interest to get this out as quickly as possible, but we must do certain things before.

I realize that we have never communicated clearly that it will take more than a few weeks’ time after the beta release to have GA ready.

Developer productivity of the teams is pretty high actually, there’s just a huge amount of work to be done including making sure that the code is secure. Achieving correctness of the implementation adds substantial effort but is crucial for functionality like the one we are building here.

14 Likes
452

Hi,
When release this feature on BTC mainnet?

453

It’s probably a good sign that people are posting on this thread without reading it.

There’s clearly some level of non-developer interest in BTC integration.

7 Likes
454

This has a major implication on performance, i.e., it will be quite a bit slower there. In order to reach, what we think is an acceptable level of performance, we need to put some more thinking and engineering effort into getting good-enough performance on such larger subnet.

After watching the demo at the global R&D subnet, I think that upping performance is the right call. Balance queries took 10 seconds and transfers took 30 seconds during the demo. That was with a 13-node subnet. I don’t think that type of latency will be good enough for end users expecting a step change in performance with the IC-BTC integration.

6 Likes
455

What difference do 30 seconds make for sending if you have to wait 1h afterwards to get the Bitcoin transaction sufficiently confirmed?

Balance queries should be faster though if the balance is already confirmed.

3 Likes
456

Optimizing retrieval of UTXO sets is one of the important pieces of work we have on our plan for the GA release.

1 Like
457

The more I read this thread, the more I realize just how uncertain this team is, regarding the final button up and security process. My gut is telling me that some other company is going to solve the puzzle before ICP or the longer this drags out, the less confident the small cumulative investors will become, dumping their investment in the future of ICP. I’m hoping I’m wrong on all fronts, because I’ve been a big picture investor in ICP.

1 Like
458

Lol! That is paranoia at work.

Why does NASA want to go to the MOON AGAIN after 50+ years before going to Mars? So that they can completely work out the kinks before landing on Mars. This is a similar thing with IC Integration with BTC.

“Only the paranoid survive”. I believe that no amount of pressure is going to affect the IC team in releasing the BTC Integration prior to its time. And that is the way it should be, imo.

3 Likes
459

My gut is telling me that there will hardly be another chance for the ICP if this feature fail and money are hacked. I fear that with all the FUD there is around the ICP after the genesis attack, the project will not survive another scandal.

So the team has to make it right the first time.

We are in a bear market, so there is no rush actually.
So take your time, I know you will make it right, I trust you :call_me_hand:

9 Likes
460

Have you heard of any other team even attempting the same thing? It is unlikely that an elite team of cryptographers has been hired to accomplish the task in secret. The only way this can go wrong is if there is some kind of security breach. Getting everything perfectly secure and working is paramount, and I think Dfinity have the right perspective on it. They know a mistake here could be fatal to the entire network.
As for small investors, sadly, they tend to get out of projects at all time lows because they don’t have the capacity or patience or foresight to hold through to the next bull phase. As @dymayday wrote, this bear market is not going to ease up any time soon. As long as the IC gets substantial upgrades in the next twelve months, it will be ready to take full advantage of the next bull run, at which time a few tokens will go from being undervalued to fair value and then dramatically overshoot even that price for a time.

2 Likes
461

Thanks to the various posts made already to respond to the comment on the timeline of the feature. @mparikh , @dymayday , and @tsetse have already mentioned why security of this is so important for the IC, and its community, including investors in the IC ecosystem. We must get this right the first time and must not have a security flaw that leads to the loss of funds.

And, indeed, not many projects are even attempting doing something like we do, especially in the area of threshold ECDSA. This is just a complex protocol and implementation and thus takes time to implement, speed up, and to ascertain its security, e.g., through internal and external audits.

Two key things we are working on currently is ensuring security of the features and increasing the performance, both not being easy tasks.

For those who repeatedly voice their criticism w.r.t. timeline, please note that a fully working beta has been released and is being used by developers, and you can be assured that the GA release is following in due time, that is, once it is finished and we are ready to launch. Your patience will be rewarded with functionality that is second to none on the market. Good things take time! Thanks for your patience and trust in the team working on this!

17 Likes
462

Any “investor” no matter the size of their investment is probably not “dumping” their ICP and will not…. A more likely scenario is their ICP is staked and therefore locked and cannot be sold. 54.5% of total supply is staked. A proper investor does not buy/sell on speculation, those are traders, investors have their ICP staked for 8-years and have read the 20-year roadmap from Dom in its entirety and surmise that they will never half to sell their investment ever, because of the proceeds that their original investment will produce in the future by spawning new neurons if that is what they choose to do.

463

Somewhat unrelated, but is there a beginner’s guide to threshold ECDSA that you recommend? Like a blog post, a textbook, or even a paper? I’m curious how it works under the cover, and why it’s a challenging endeavor.

2 Likes