# Optional: Helper scripts

The following scripts assume that you have created the necessary config files and started the bitcoin monitor and provider binaries (see [Installation](/ipc-btc-scaling-docs/user-guide-for-using-subnets/installation.md)). We recommend that you start each of the following scripts in a separate terminal.

### Watch log files

When the `bitcoin-ipc` container is started, it automatically runs the a Bitcoin Monitor and a Bitcoin Provider for each of the four validators. Moreover, the scripts `spin_up_subnet_a_from_container.sh` and `spin_up_subnet_b_from_container.sh` , that deploy the subnet validators, start a Relayer for each validator. The log files live inside the container at `/root/logs/`. To see them:

```bash
# From your host machine
docker exec bitcoin-ipc tail -f /root/logs/monitor-validator1.log
```

```bash
# From your host machine
docker exec bitcoin-ipc tail -f /root/logs/provider-validator1.log
```

```bash
# From your host machine
docker exec bitcoin-ipc tail -f /root/logs/relayer-subnet-a-validator1.log
```

```bash
# From your host machine
docker exec bitcoin-ipc tail -f /root/logs/relayer-subnet-b-validator1.log
```

And accordingly for  `validator2` , `validator3` , `validator4` , `validator5` , `user1` , `user2` .

### Mine blocks on bitcoin

The script mines a regtest block every 10 seconds. 

If you are using the default Docker-based deployment, the script is automatically started upon creation of the `bitcoin-ipc` container. You can start it manually running in the `bitcoin-ipc` container: 

```bash
# Inside the `bitcoin-ipc` container
/workspace/bitcoin-ipc/scripts/miner.sh
```

If you are using the alternative method, running bitcoin core on your host machine, you can run the script from the root of the `bitcoin-ipc` repo:

```bash
# From your host machine
./scripts/miner.sh
```

### Get regtest block height

The script queries and returns the block height on the local regtest network every 10 seconds.

If you are using the default Docker-based deployment, the script is run as follows:

```bash
# From your host machine
docker exec bitcoin-ipc /workspace/bitcoin-ipc/scripts/l1_block_checker.sh
```

If you are using the alternative method, running bitcoin core on your host machine:

```bash
# From your host machine
./scripts/l1_block_checker.sh
```

### Get status of a subnet, as seen from bitcoin

In this following script, make sure that you 

* update the bitcoin provider port (default in our setup: `3030`) and the corresponding auth token (default in our setup: `validator1_auth_token`), if you have changed them
* use the ID of a subnet already created.

Run the following command on your host machine:

```bash
# From your host machine
curl -X POST http://localhost:3030/api \
-H "Content-Type: application/json" \
-H "Authorization: Bearer validator1_auth_token" \
-d '{
    "jsonrpc": "2.0",
    "method": "getsubnet",
    "params": {
            "subnet_id": "'"$SUBNET_ID"'"
    },
    "id": 1
}' | jq
```

The command returns, among others, the current committee number (the validator set can change, as we will see in [Validator Operations within subnet](/ipc-btc-scaling-docs/user-guide-for-using-subnets/publish-your-docs-2.md)), the current validator set and the collateral staked by each validator, information on pending committee updates, and information on whether the subnet has been or will be killed.

### Get submitted kill requests, as seen from bitcoin

It returns the kill requests, if there are any, for a subnet. We will use it in [Kill subnet](/ipc-btc-scaling-docs/user-guide-for-using-subnets/kill-subnet.md) to keep track of active kill requests and the validators that have voted for each of them. As before, please make sure you 

* are using the correct port and auth token, if you have changed them
* use the subnet id of an already created subnet

Run the following command on your host machine:

```bash
# From your host machine
curl -X POST http://localhost:3030/api \
-H "Content-Type: application/json" \
-H "Authorization: Bearer validator1_auth_token" \
-d '{
    "jsonrpc": "2.0",
    "method": "getkillrequests",
    "params": {
            "subnet_id": "<THE ID OF A SUBNET HERE>"
    },
    "id": 1
}' | jq
```

### **L2 Subnet tools**

The following scripts operate on a specific L2 subnet. They can be run only **after** the docker containers for the subnet have been started (in page  [Optional: Manual subnet creation and deployment](/ipc-btc-scaling-docs/user-guide-for-using-subnets/optional-manual-subnet-creation-and-deployment.md)). The scripts are run from the root of the `bitcoin-ipc` repo.

#### Get subnet block height

It queries and prints the current block height of a subnet every 1 second.  You will need the `$ETH_API_PORT` of one of the validators of the subnet you want to query — by default in this demo:

* Subnet A
  * `8545` for validator 1
  * `8645` for validator 2
  * `8745` for validator 3
  * `8845` for validator 4
  * `8945` for validator 5
* Subnet B:
  * `9545` for validator 1
  * `9645` for validator 2
  * `9745` for validator 3
  * `9845` for validator 4
  * `9945` for validator 5

```bash
# From your host machine
./scripts/l2_block_checker.sh $ETH_API_PORT
```

#### Get validator status

It shows information for a validator by querying its CometBFT container. You will need the `$COMETBFT_PORT` of one of the validators of the subnet you want to query — by default in this demo:

* Subnet A
  * `26657` for validator 1
  * `26757` for validator 2
  * `26857` for validator 3
  * `26957` for validator 4
  * `27057` for validator 5
* Subnet B:
  * `27657` for validator 1
  * `27757` for validator 2
  * `27857` for validator 3
  * `27957` for validator 4
  * `28057` for validator 5

```bash
# From your host machine
./scripts/validator_status.sh $COMETBFT_PORT
```

#### Get validator set

It shows all current validators and their voting power for a subnet.  As with the previous command, you need the `$COMETBFT_PORT` of one of the validators of the subnet you want to query.

<pre class="language-bash"><code class="lang-bash"># From your host machine
<strong>./scripts/list_validators.sh $COMETBFT_PORT
</strong></code></pre>

In the returned information notice the field `voting_power` of each validator.

{% hint style="success" %}
**How the voting power is computed:**

The voting power of each validator corresponds to the amount it stakes in the subnet, expressed as an integer between 1 and 10,000.

For example, if four validators stake 2, 1.1, 1.5, and 1.8 bitcoin each, their voting power will be 2000, 1100, 1500, and 1800, respectively.
{% endhint %}

#### Get balances in subnet

It shows the balance in subnet `$SUBNET_ID` of every wallet of type `btc` created with `ipc-cli` .

If you are using the default Docker-based deployment, run this script from inside the container:

```bash
# Inside the `bitcoin-ipc` container
/workspace/bitcoin-ipc/scripts/balancer.sh $SUBNET_ID
```

If you are using the alternative method, running `ipc-cli` on your host machine,  from the root of the `bitcoin-ipc` repo on your machine:

```bash
# From your host machine
./scripts/balancer.sh $SUBNET_ID
```

### Spin up subnet A and subnet B

The following tools can be used to start the docker containers for four validators for two subnets. We will use them in [Optional: Manual subnet creation and deployment](/ipc-btc-scaling-docs/user-guide-for-using-subnets/optional-manual-subnet-creation-and-deployment.md).

```bash
./scripts/spin_up_subnet_a.sh $SUBNET_ID 
./scripts/spin_up_subnet_b.sh $SUBNET_ID 
./scripts/spin_up_subnet_a_from_container.sh $SUBNET_ID [validator5|validator6]
./scripts/spin_up_subnet_b_from_container.sh $SUBNET_ID [validator5|validator6]
./scripts/bootstrap_subnet_from_container
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://bitcoin-scaling-labs-docs.gitbook.io/ipc-btc-scaling-docs/user-guide-for-using-subnets/optional-helper-scripts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.