DFINITY Foundation

Synapse.vote (original)

ICDevs.org

CryptoIsGood

Anvil

ICPL.app

ysyms

The Accumulators’ Neuron

RawTech Venture

Paul Young

ICPMANUAL

8yeargangDAO

Isaac Valadez

Krzysztof Żelazko

Nicolas.ic

Smaug’s Neuron for Retail Investors

ICLight.io

Synapse.vote (NEW)

Taggr Network

CodeGov.org

Sonic AMM

Rakeoff.io

OpenChat

ELNA AI

GEEKFACTORY

ICP Hub México

ICP Hub Poland

Jerry Banfield

WaterNeuron

Internet Computer Association

Arthur’s Neuron (used to be cycle_dao)

Inactive (Request Removal) - The Fools' Court

$STACK

Always Rejects

John Wiegley

# Rebootstrap the Bitcoin Testnet Canister

## Summary

The Bitcoin testnet often suffers from "block storms" where the block rate
rises sharply due to difficulty resets. Recent "block storms" were severe
enough that the canister's main memory is too low to perform an upgrade,
making the canister un-upgradable.

Since then, the following enhancements have been made to improve the canister's
memory footprint:

* [More efficient serialization of unstable blocks](https://github.com/dfinity/bitcoin-canister/pull/305)
* [Reduce memory footprint of pre_upgrade by 50%](https://github.com/dfinity/bitcoin-canister/pull/306)

These enhancements cannot be deployed, however, because the canister has become
un-upgradable. The way around this is to rebootstrap the canister. In other
words, the canister's state is recomputed offline and then is uploaded to
replace the current canister.

There will be two proposals to rebootstrap the Bitcoin testnet canister:

1. (This one) A proposal to install an `uploader` canister, replacing the
   current Bitcoin testnet canister. The `uploader` canister is pre-configured
   to only accept the Bitcoin testnet state that has been computed offline.
   **The Bitcoin testnet canister will be unavailable during this time.**

2. A proposal to upgrade the `uploader` canister into the Bitcoin canister,
   which will then be initialized with Bitcoin testnet state up to height
   2867460 and will resume syncing from there.

Rebootstrapping the canister such that it starts syncing from height 2867460
rather than from genesis reduces the downtime significantly. **The expected
downtime will be ~2 days** with this approach, whereas syncing from genesis
will require a downtime of around 4 weeks.

Note the bootstrapping process was done in the past to initialize the Bitcoin
mainnet canister, so it is a process that has been done before.

## Verification

### Wasm Verification

The verification process:
- Has only been tested on Linux (i.e. not guaranteed to work on Windows or macOS)
- Can take up to 24 hours
- Needs > 400GiB of disk space

```shell
# Clone the bitcoin-canister repo.
$ git clone git@github.com:dfinity/bitcoin-canister.git
$ cd bitcoin-canister
$ git checkout 32102befcb7358a95b6d464b814d95482cd068dc
$ cd bootstrap # move to the bootstrap directory
```

Follow the instructions in `./bootstrap/README.md`, using the following values
for the environment variables:

```
BITCOIN_DIR=<path/to/bitcoin-22>
HEIGHT=2867460
STABILITY_THRESHOLD=50
NETWORK=testnet
```

By the end of the process, you'll have generated the file `bootstrap/chunk_hashes.txt`
with the following checksum:

```
0e2a5982a2a28e36c172c9726395bb894b7719612f70c13972b3146e29f6a356  chunk_hashes.txt
```

In case of a checksum mismatch, the following are checksums of intermediate files
to help with debugging:

In the `./bootstrap` directory:
```
b77a9f4a7764ff6ebc7e63d046a716d4dffc9d0b68ee53a41c4651ebef1d6d2e  canister_state.bin
eff7e1e865098fdb9309e391ac385a3cb29bd3d7b41bcdc0c5da7725ee2c852b  utxodump.csv
96133dabc57958e7568d7130e91658a46e5673ed0016b90f4ddfedc11cc22482  utxodump_shuffled.csv
1102c84d4a12a6e5ff09cd3823d85dea1dff2c2b30b8f4c24bfafa10db15c016  block_headers
```

In the `./bootstrap/canister_state` directory:
```
46c5bf1cd7a1f4fa0600b6755d62e04546ff7a90dbda1cf60291b10535198642  address_utxos
f0c19303b1c71caf00a52068c9831edf21489ff9a9ec0eeb9a7c3c4823981c79  balances
aaf5b4b76fefcfb4337088f686853bdfa2ffa24ff5a699740415d39346906d2c  large_utxos
57635e37d0a5110e068c2274cd63a0fd623ba7d9c2ad8d4b6f67c754d6f63ef3  medium_utxos
96f17754918d809b0dd41c3995c267efe67b857c46c42c4216637a8ce154e059  small_utxos
```

Build the uploader canister, which incorporates `chunk_hashes.txt` into the binary:

```
# From the root of the repository.

# Build all, specifying the path to chunk_hashes.txt
$ docker build --build-arg CHUNK_HASHES_PATH=/bootstrap/chunk_hashes.txt  -t canisters .

# Extract canister's wasm.
$ docker run --rm --entrypoint cat canisters /uploader.wasm.gz > uploader.wasm.gz

# Calculate SHA-256 of the canister's wasm.
$ sha256sum uploader.wasm.gz
```

You should then see the following output:

```shell
01a55973cefc467602ca65cda4daab9eacaca2623cbf26210e49b67468eee65e  uploader.wasm.gz
```

### Upgrade Arguments Verification
The `uploader` canister is initialized with the size of the state to be uploaded in
Wasm pages. The size of `canister_state.bin` should be 1462657 Wasm pages.

```shell
$ didc encode -t '(nat64)' "(1462657)"
```

Expected output:

```shell
4449444c0001788151160000000000
```


Upgrade NNS Canister: g4xu7-jiaaa-aaaan-aaaaq-cai to wasm with hash: 01a55973cefc467602ca65cda4daab9eacaca2623cbf26210e49b67468eee65e