Direct Integration with Bitcoin

An amazing project which has a high futuristic growth potential, capable of moving to the moon

Hey Manu,

Has Dfinity given further thought as to how it wants to approach the Ethereum integration? It will be amazing when we can use ICP Dexes to do bitcoin <> eth swaps. Will create demand to burn cycles among folks who don’t even want to use icp!

4 Likes

Hey everyone, we’re happy to share that we are still on track to launch the Bitcoin integration this week. Since the Bitcoin mainnet canister will be under NNS control (just like existing NNS canisters and internet identity), the launch will consist of three NNS proposals, all in the topic of “system canister management”:

  1. A proposal to install an uploader canister. This is a canister that will be used to upload a precomputed state of the Bitcoin mainnet canister at a height of 764,684.

  2. A proposal to upgrade the uploader canister to the Bitcoin mainnet canister. The canister will start syncing new blocks, but the endpoints of the canister will be disabled.

  3. A proposal to enable the endpoints of the Bitcoin mainnet canister, making them accessible and concluding the launch.

Why upload a precomputed state of the Bitcoin mainnet canister?

The alternative to precomputing the state of the canister would be to sync from genesis. However, a full sync of Bitcoin mainnet from genesis would take weeks. Precomputing the state offline, on the other hand, takes ~24 hours and uploading it takes ~12-18 hours.

How can I verify the Wasm hash of the uploader canister and the bitcoin canister?

  • Clone the bitcoin-canister repo.
  • Checkout the launch branch.
  • Run docker build -t canisters . to build the canisters and output their Wasm hashes.

How can I verify the state that will be uploaded?

We’ll be uploading the state using what we call the uploader canister. Once the uploader canister is deployed, we can upload “chunks” of the bitcoin canister’s state using ingress messages. The uploader canister is initialized with the hashes of each of these chunks to verify their correctness, meaning that the NNS still controls the state that will be uploaded. Here you’ll find the hashes of the chunks, which are hard-coded in the uploader canister.

If you’d like to compute the Bitcoin canister’s state for yourself to verify the correctness of these hashes, please follow the instructions here, setting the HEIGHT to 764684. Note that the computation takes around 24 hours. At different points in the computation process, the checksums of various files are emitted. If everything is working as expected, you should see the following checksums:

sha256sum unstable_blocks
c62e653e80c11c5463cfd24af8d26eef4392d6b9600ab6278d61f29f159c1e1a  unstable_blocks

sha256sum block_headers
b7047039bccb1eb81c7df97ba4dcd04ae6163277909bcded7789b73512e29544  block_headers

sha256sum utxodump.csv
ec09112894aad807b90f9991be76105e41e9038687b59dce5a1aaadcedf52ddc  utxodump.csv

sha256sum utxodump_shuffled.csv
9730fddcf70afc60bfb94d0bcddd82b2e807cf57842733176dec1d31b0dedc05  utxodump_shuffled.csv

sha256sum canister_state.bin
1cf90cc7abdd859be021f35e1066965b7d1f23add33ddc4650ff3d27663211ec  canister_state.bin

Once you’re done with the instructions, you’ll have a file called chunk_hashes.txt, which should be identical to the hard-coded chunk_hashes.txt file in the uploader canister.

git switch launch   # switch to the launch branch.

# The chunk hashes you computed and the ones hard-coded in the uploader canister
# should be identical.
diff chunk_hashes.txt ./uploader/src/chunk_hashes.txt 

If you managed to recompute this state and verify its integrity, or if you tried but ran into issues, please let us know here!

40 Likes

I am running the verification steps and will report back when it’s done!

16 Likes

Quick update: we just submitted proposal 94253, the first of the three proposals mentioned in my previous post, that installs the uploader canister.

20 Likes

Does this mean Bitcoin Integration is finally released after the proposal passes?

No, the first proposal will allow us to start uploading the bitcoin state. The Bitcoin integration will be considered released once all the three proposals I mention are submitted and passed.

9 Likes

Why don’t you submit the proposals at the same time? Do we really have to wait 3 days for each proposal to pass (in total 9 days)?

3 Likes

I managed to complete all the verification steps in an ubuntu VM on my laptop, and also landed on the initial canister state

1cf90cc7abdd859be021f35e1066965b7d1f23add33ddc4650ff3d27663211ec canister_state.bin

It did take a long time to sync the full bitcoin blockchain and compute everything from it. I computed unstable_blocks and block_headers without issues. I did run into an issue with computing utxodump.csv and utxodump_shuffled.csv: it seems that sort -n is not fully deterministic and my result was slightly differently sorted than @ielashi’s. I resolved this by downloading @ielashi’s versions, and ensured that what I computed is equal to his versions after doing a sort (without the -n), such that I’m still entirely sure that it contains the right UTXOs. From that, I computed the expected canister_state.bin.

We’ll make @ielashi’s utxodump_shuffled.csv available here, such that if anybody else runs into the sort -n issue, they can follow the same steps as I did to still verify the correctness of the initial state.

13 Likes

Mooi dat een Nederlander betrokken is bij zo’n belangrijke operatie.

5 Likes

Truly hope cefi exchanges allow ckBTC deposits and withdrawals soon after it is live. I sent ICP to crypto.com earlier and it instantly arrived, like not more than 4 seconds later (not kidding). Imagine how insanely cool itd be doing that with bitcoin (even if its the wrapped version). So mindblowing to even think about it.

5 Likes

@icypee Technically, we could submit all 3 proposals at once. However, they need to be executed in this particular order that has been listed by @ielashi. After being submitted, in theory these proposals could pass at any time, as long as the conditions are met. Therefore, it is the easiest to submit 1 by 1 and confirm that everything works as expected in between.

It’s not necessary to wait 3 days for these proposals to be adopted. They follow the same pattern as other proposals that upgrade NNS canisters, like the governance canister, where the proposals will be adopted once the foundation votes. The first proposal has already been adopted and executed and we are now in the process of voting for the second proposal.

7 Likes

IIRC it has to do with some LOCALE setting. I remember I had to sync my locale between machines when I ran into sort problems on some project.

I’d look into first setting export LC_ALL= <something> on both machines and comparing the result of sort -n, as the likely solution to get deterministic sorting.

To add more for current status, both of the round 2 proposals seem executed, so we’re probably waiting just for the last one :pray: :heart_eyes: :rocket:

2 Likes

Is it necessary for us to find another third-party contract auditor?

1 Like

This long-awaited moment is finally coming. If the third proposal is passed, does it mean that the mainnet BTC integration has been completed?

2 Likes

Tbh, I would say “launched” or “shipped” but “completed” is not quite the right word because we expect lots of updates to improve once it’s shipped/launched. Team will not abandon BTC integration, but continue improving it.

But YES! the APIs for developers will be there after the proposal. Improving docs, performance, developer experience, etc… will continue of course.

I think it’s fair to say “that launch will be complete” since functionality will be shipped.

Do you agree with that @dieter.sommer @Manu ?

13 Likes

third proposal has been submitted it’s happening pee holders
proposal:94858

4 Likes

Executed ! :clap: :clap: :fire:

4 Likes

Now is time to party ! :champagne: :champagne: :champagne: :champagne:
Tomorow eth integration :slight_smile:
And also we need some marketing. I hope we will reach cointelegraph this time and other major media

3 Likes