Refactor/bitvm

.claude/commands/bridge-out.md

@@ -25,11 +25,11 @@ Initiate Bridge Out via the `bridge-out` binary (payInvoice quote -> swap initia
 
 3. Check if the `bridge-out` binary exists at `./bin/bridge-out`. If not, run the install script to download it:
    ```bash
-   .claude/commands/install-bitvm2.sh install
+   .claude/commands/install-bitvm.sh install
    ```
    To upgrade to the latest version:
    ```bash
-   .claude/commands/install-bitvm2.sh upgrade
+   .claude/commands/install-bitvm.sh upgrade
    ```
    The script auto-detects the platform (x86_64-linux / aarch64-macos), downloads from GitHub Releases,
    verifies the sha256 checksum, and installs all binaries to `./bin/`.

.claude/commands/challenge.md

@@ -31,7 +31,7 @@ Use the `/run-challenger-node` skill to start one, or see `deployment/README.md`
 
 5. Check if the `challenge` binary exists at `./bin/challenge`. If not, run:
    ```bash
-   .claude/commands/install-bitvm2.sh install
+   .claude/commands/install-bitvm.sh install
    ```
 
 6. Run the command using the pre-built binary:

.claude/commands/install-bitvm2.sh → .claude/commands/install-bitvm.sh

@@ -4,7 +4,7 @@ set -euo pipefail
 REPO="GOATNetwork/bitvm2-node"
 API_URL="https://github.com/ghapi/repos/${REPO}/releases"
 INSTALL_DIR="./bin"
-VERSION_FILE=".bitvm2-version"
+VERSION_FILE=".bitvm-version"
 
 usage() {
     cat <<EOF
@@ -71,7 +71,7 @@ do_install() {
     local platform
     platform="$(detect_platform)"
 
-    local tarball="bitvm2-node-${version}-${platform}.tar.gz"
+    local tarball="bitvm-node-${version}-${platform}.tar.gz"
     local base_url="https://github.com/${REPO}/releases/download/${version}"
     local url="${base_url}/${tarball}"
     local sha_url="${url}.sha256"

.claude/commands/pegin-request.md

@@ -27,11 +27,11 @@ Send a pegin request to GoatChain via the `pegin-request` binary.
 
 3. Check if the `pegin-request` binary exists at `./bin/pegin-request`. If not, run the install script to download it:
    ```bash
-   .claude/commands/install-bitvm2.sh install
+   .claude/commands/install-bitvm.sh install
    ```
    To upgrade to the latest version:
    ```bash
-   .claude/commands/install-bitvm2.sh upgrade
+   .claude/commands/install-bitvm.sh upgrade
    ```
    The script auto-detects the platform (x86_64-linux / aarch64-macos), downloads from GitHub Releases, verifies the sha256 checksum, and installs all binaries to `./bin/`.
 

.claude/commands/pegout.md

@@ -41,7 +41,7 @@ Use the `/run-operator-node` skill to start one, or see `deployment/README.md` (
 
 4. Check if the `pegout` binary exists at `./bin/pegout`. If not, run:
    ```bash
-   .claude/commands/install-bitvm2.sh install
+   .claude/commands/install-bitvm.sh install
    ```
 
 5. Run the command using the pre-built binary:

.claude/commands/run-challenger-node.md

@@ -1,4 +1,4 @@
-Run a BitVM2 Challenger node locally.
+Run a BitVM Challenger node locally.
 
 The Challenger verifies operator operations and submits challenges if necessary.
 
@@ -8,11 +8,11 @@ The Challenger verifies operator operations and submits challenges if necessary.
    - **network**: Which network? `testnet4` or `regtest`
    - **rpc_addr**: RPC listen address. Default: `127.0.0.1:8906`
    - **p2p_port**: P2P listen port. Default: `8449` (testnet4) or `8450` (regtest)
-   - **db_path**: SQLite database path. Default: `sqlite:$PWD/bitvm2-node.db`
+   - **db_path**: SQLite database path. Default: `sqlite:$PWD/bitvm-node.db`
 
 2. Ensure the `.env` file exists in the working directory. Template configs are at:
-   - **testnet4**: `deployment/testnet4/bitvm2-nodes/challenge_0/.env.challenge_0`
-   - **regtest**: `deployment/regtest/bitvm2-nodes/challenge_0/.env.challenge_0`
+   - **testnet4**: `deployment/testnet4/bitvm-noded/challenge_0/.env.challenge_0`
+   - **regtest**: `deployment/regtest/bitvm-noded/challenge_0/.env.challenge_0`
 
    The user **must** fill in these required secrets:
    - `BITVM_SECRET` - Node BTC key (hex or `seed:...`)
@@ -21,23 +21,23 @@ The Challenger verifies operator operations and submits challenges if necessary.
 
    Copy the template if needed:
    ```bash
-   cp deployment/<network>/bitvm2-nodes/challenge_0/.env.challenge_0 .env
+   cp deployment/<network>/bitvm-noded/challenge_0/.env.challenge_0 .env
    ```
 
-3. Check if the `bitvm2-noded` binary exists at `./bin/bitvm2-noded`. If not, run:
+3. Check if the `bitvm-noded` binary exists at `./bin/bitvm-noded`. If not, run:
    ```bash
-   .claude/commands/install-bitvm2.sh install
+   .claude/commands/install-bitvm.sh install
    ```
 
 4. Start the challenger node:
 
 ```bash
-./bin/bitvm2-noded --rpc-addr <rpc_addr> --db-path <db_path> --p2p-port <p2p_port> --bootnodes "$BOOTNODES"
+./bin/bitvm-noded --rpc-addr <rpc_addr> --db-path <db_path> --p2p-port <p2p_port> --bootnodes "$BOOTNODES"
 ```
 
 To run in the background:
 ```bash
-nohup ./bin/bitvm2-noded --rpc-addr <rpc_addr> --db-path <db_path> --p2p-port <p2p_port> --bootnodes "$BOOTNODES" >challenger_$(date +'%Y%m%d').log 2>&1 &
+nohup ./bin/bitvm-noded --rpc-addr <rpc_addr> --db-path <db_path> --p2p-port <p2p_port> --bootnodes "$BOOTNODES" >challenger_$(date +'%Y%m%d').log 2>&1 &
 ```
 
 5. Verify the node is running:
@@ -49,9 +49,9 @@ Should return `Hello, World!`.
 ### Example (testnet4)
 
 ```bash
-cp deployment/testnet4/bitvm2-nodes/challenge_0/.env.challenge_0 .env
+cp deployment/testnet4/bitvm-noded/challenge_0/.env.challenge_0 .env
 # Edit .env to fill in BITVM_SECRET, GOAT_ADDRESS, PEER_KEY
-./bin/bitvm2-noded --rpc-addr 127.0.0.1:8906 --db-path sqlite:$PWD/bitvm2-node.db --p2p-port 8449 --bootnodes /ip4/34.215.238.232/tcp/8445/p2p/12D3KooWCrPTAmhFdC5DBGgkxZvJi6iuSeiDWKRL87isrt4iMHXv
+./bin/bitvm-noded --rpc-addr 127.0.0.1:8906 --db-path sqlite:$PWD/bitvm-node.db --p2p-port 8449 --bootnodes /ip4/34.215.238.232/tcp/8445/p2p/12D3KooWCrPTAmhFdC5DBGgkxZvJi6iuSeiDWKRL87isrt4iMHXv
 ```
 
 For full deployment documentation, see `deployment/README.md` (section **Challenger**).

.claude/commands/run-operator-node.md

@@ -1,4 +1,4 @@
-Run a BitVM2 Operator node locally.
+Run a BitVM Operator node locally.
 
 The Operator manages bridge operations, kickoff processing, and pegout (Gateway.initWithdraw).
 
@@ -8,11 +8,11 @@ The Operator manages bridge operations, kickoff processing, and pegout (Gateway.
    - **network**: Which network? `testnet4` or `regtest`
    - **rpc_addr**: RPC listen address. Default: `127.0.0.1:8902`
    - **p2p_port**: P2P listen port. Default: `8445` (testnet4) or `8446` (regtest)
-   - **db_path**: SQLite database path. Default: `sqlite:$PWD/bitvm2-node.db`
+   - **db_path**: SQLite database path. Default: `sqlite:$PWD/bitvm-node.db`
 
 2. Ensure the `.env` file exists in the working directory. Template configs are at:
-   - **testnet4**: `deployment/testnet4/bitvm2-nodes/operator_0/.env.operator_0`
-   - **regtest**: `deployment/regtest/bitvm2-nodes/operator_0/.env.operator_0`
+   - **testnet4**: `deployment/testnet4/bitvm-noded/operator_0/.env.operator_0`
+   - **regtest**: `deployment/regtest/bitvm-noded/operator_0/.env.operator_0`
 
    The user **must** fill in these required secrets:
    - `BITVM_SECRET` - Operator BTC private key (hex)
@@ -24,23 +24,23 @@ The Operator manages bridge operations, kickoff processing, and pegout (Gateway.
 
    Copy the template if needed:
    ```bash
-   cp deployment/<network>/bitvm2-nodes/operator_0/.env.operator_0 .env
+   cp deployment/<network>/bitvm-noded/operator_0/.env.operator_0 .env
    ```
 
-3. Check if the `bitvm2-noded` binary exists at `./bin/bitvm2-noded`. If not, run:
+3. Check if the `bitvm-noded` binary exists at `./bin/bitvm-noded`. If not, run:
    ```bash
-   .claude/commands/install-bitvm2.sh install
+   .claude/commands/install-bitvm.sh install
    ```
 
 4. Start the operator node:
 
 ```bash
-./bin/bitvm2-noded --rpc-addr <rpc_addr> --db-path <db_path> --p2p-port <p2p_port> --bootnodes "$BOOTNODES"
+./bin/bitvm-noded --rpc-addr <rpc_addr> --db-path <db_path> --p2p-port <p2p_port> --bootnodes "$BOOTNODES"
 ```
 
 To run in the background:
 ```bash
-nohup ./bin/bitvm2-noded --rpc-addr <rpc_addr> --db-path <db_path> --p2p-port <p2p_port> --bootnodes "$BOOTNODES" >operator_$(date +'%Y%m%d').log 2>&1 &
+nohup ./bin/bitvm-noded --rpc-addr <rpc_addr> --db-path <db_path> --p2p-port <p2p_port> --bootnodes "$BOOTNODES" >operator_$(date +'%Y%m%d').log 2>&1 &
 ```
 
 5. Verify the node is running:
@@ -52,9 +52,9 @@ Should return `Hello, World!`.
 ### Example (testnet4)
 
 ```bash
-cp deployment/testnet4/bitvm2-nodes/operator_0/.env.operator_0 .env
+cp deployment/testnet4/bitvm-noded/operator_0/.env.operator_0 .env
 # Edit .env to fill in BITVM_SECRET, GOAT_ADDRESS, PEER_KEY, GOAT_PRIVATE_KEY
-./bin/bitvm2-noded --rpc-addr 127.0.0.1:8902 --db-path sqlite:$PWD/bitvm2-node.db --p2p-port 8445 --bootnodes /ip4/34.215.238.232/tcp/8445/p2p/12D3KooWCrPTAmhFdC5DBGgkxZvJi6iuSeiDWKRL87isrt4iMHXv
+./bin/bitvm-noded --rpc-addr 127.0.0.1:8902 --db-path sqlite:$PWD/bitvm-node.db --p2p-port 8445 --bootnodes /ip4/34.215.238.232/tcp/8445/p2p/12D3KooWCrPTAmhFdC5DBGgkxZvJi6iuSeiDWKRL87isrt4iMHXv
 ```
 
 For full deployment documentation, see `deployment/README.md` (section **Operator**).

.claude/commands/upgrade.md

@@ -1,19 +1,19 @@
-Upgrade or install bitvm2-node binaries via `install-bitvm2.sh`.
+Upgrade or install bitvm-node binaries via `install-bitvm.sh`.
 
 ## Instructions
 
 1. Check the currently installed version:
    ```bash
-   .claude/commands/install-bitvm2.sh version
+   .claude/commands/install-bitvm.sh version
    ```
 
 2. If $ARGUMENTS contains a target version (e.g. `v0.3.2`), use that version. Otherwise, upgrade to the latest release.
 
 3. Run the upgrade:
    ```bash
-   .claude/commands/install-bitvm2.sh upgrade $ARGUMENTS
+   .claude/commands/install-bitvm.sh upgrade $ARGUMENTS
    ```
 
-4. If the script is missing or not executable, inform the user that `.claude/commands/install-bitvm2.sh` is required and offer to check if it exists.
+4. If the script is missing or not executable, inform the user that `.claude/commands/install-bitvm.sh` is required and offer to check if it exists.
 
 5. Report the result to the user: what version was installed before, what version is installed now, and list the installed binaries.

.env.template

@@ -22,7 +22,7 @@ GOAT_PRIVATE_KEY=
 GOAT_ADDRESS=
 
 # protocol name
-PROTO_NAME=bitvm2t3
+PROTO_NAME=bitvmt3
 
 # setup bootnodes, separate multiple nodes by comma ",".
 BOOTNODES=

.github/workflows/ci_time_consuming.yml

@@ -18,5 +18,5 @@ jobs:
       - name: Run all unit tests
         run:  |
           source ~/.zkm-toolchain/env 
-          cd crates/bitvm2-ga
+          cd crates/bitvm-gc
           cargo test -r --features ci-tests -- --nocapture

.github/workflows/release.yml

@@ -74,7 +74,7 @@ jobs:
       - name: Collect binaries
         run: |
           BINS=(
-            "target/release/bitvm2-noded"
+            "target/release/bitvm-noded"
             "target/release/sequencer-set-publish"
             "target/release/challenge"
             "target/release/send-rbf"
@@ -106,7 +106,7 @@ jobs:
             fi
           done
 
-          ARCHIVE_NAME="bitvm2-node-${VERSION}-${PLATFORM}.tar.gz"
+          ARCHIVE_NAME="bitvm-node-${VERSION}-${PLATFORM}.tar.gz"
           tar -czf "release-artifacts/${ARCHIVE_NAME}" -C "$STAGING_DIR" .
           $CHECKSUM_CMD "release-artifacts/${ARCHIVE_NAME}" > "release-artifacts/${ARCHIVE_NAME}.sha256"
 
@@ -129,4 +129,4 @@ jobs:
           echo "### Version: $VERSION" >> $GITHUB_STEP_SUMMARY
           echo "" >> $GITHUB_STEP_SUMMARY
           echo "### Archive:" >> $GITHUB_STEP_SUMMARY
-          ls -1 release-artifacts/ | sed 's/^/- /' >> $GITHUB_STEP_SUMMARY
+          ls -1 release-artifacts/ | sed 's/^/- /' >> $GITHUB_STEP_SUMMARY

README.md

@@ -1,6 +1,6 @@
-# GOAT Bitvm2 Node
+# GOAT BitVM Node
 
-GOAT Network's BitVM2 bridge implementation. See [GOAT BitVM2 Whitepaper](https://www.goat.network/bitvm2-whitepaper) for more details.
+GOAT Network's BitVM bridge implementation. See [GOAT BitVM Whitepaper](https://www.goat.network/bitvm2-whitepaper) for more details.
 
 ## Layout
 

audit/TLAPlus-20260710.md

@@ -1,10 +1,10 @@
-# BitVM2 Node — Formal Verification Audit (Round 1)
+# BitVM Node — Formal Verification Audit (Round 1)
 
 **Branch:** `audit/round-1` · **Base:** `gc-v2` · **Method:** TLA+ model checking (TLC) · **Status:** all 8 formally-proven findings from this round are now **fixed and verified** in commit [`991faaa`](https://github.com/GOATNetwork/bitvm2-node/commit/991faaabdb56c747103e8f1c6d6477c638ccfc4c) ("Dev fix #418", authored independently by a teammate — not applied by this audit). Two smaller, lower-priority adjacent defects noted under Finding 8 remain open.
 
 ## Executive summary
 
-This audit used TLA+ to formally model the BitVM2 graph's status bookkeeping (local database state), the peg-out transaction graph's timelock configuration, and — a later round — the Bitcoin transaction graph's shared connectors directly, checking each against explicit safety and liveness properties rather than relying on manual code review alone. **Eight real issues were found**, each backed by a machine-checked counterexample (not a hypothetical), and a verified-correct fix design was produced for each. Three further checks were run and each, for a specific and verifiable reason, found **no** new issue: whether having multiple independent watchtowers/verifiers introduces new problems beyond the single-actor case (Finding 5), whether `GoatTxProcessingStatus` — the last multi-writer-shaped enum in the codebase — has the same class of race as the others (Finding 8), and whether `operator_commit`'s margin against the shared `ConnectorF` UTXO — previously only a scalar Rust assertion — actually holds with real shipped values (Finding 10).
+This audit used TLA+ to formally model the BitVM graph's status bookkeeping (local database state), the peg-out transaction graph's timelock configuration, and — a later round — the Bitcoin transaction graph's shared connectors directly, checking each against explicit safety and liveness properties rather than relying on manual code review alone. **Eight real issues were found**, each backed by a machine-checked counterexample (not a hypothetical), and a verified-correct fix design was produced for each. Three further checks were run and each, for a specific and verifiable reason, found **no** new issue: whether having multiple independent watchtowers/verifiers introduces new problems beyond the single-actor case (Finding 5), whether `GoatTxProcessingStatus` — the last multi-writer-shaped enum in the codebase — has the same class of race as the others (Finding 8), and whether `operator_commit`'s margin against the shared `ConnectorF` UTXO — previously only a scalar Rust assertion — actually holds with real shipped values (Finding 10).
 
 **Update: all 8 findings are now fixed.** Commit `991faaa`, contributed independently to this branch, applies real fixes for every one of them. This audit's own contribution to that fix landing was zero — the fixes were designed and written by someone else — but every fix was independently re-verified against this audit's own TLA+ models before being accepted as correct: read against the actual diff (not the commit message), and for the two timelock-margin findings (4, 9), re-checked with TLC using the *actual new shipped numbers*, not just the originally-proposed values. Each Finding below is marked **FIXED (commit `991faaa`)** with what the real applied fix looks like. In several cases the shipped fix is more thorough than what this audit's own fix design proposed (see Findings 1, 6 in particular).
 
@@ -98,7 +98,7 @@ Before generalizing Finding 4's fix, it was necessary to check whether the real
 
 `InstanceBridgeOutStatus` (`Initialize`/`Claim`/`Timeout`/`Refund`, `crates/store/src/schema.rs:223-229`) is written from **three** independently-scheduled, uncoordinated places, none of which share a transaction spanning read+decide+write:
 
-- The RPC-service task (`node/src/rpc_service/handler/bitvm2_handler.rs:308-368`, `bridge_out_init_tag`) — a stale-read-then-full-row-`upsert_instance`, sets `Initialize` unconditionally as part of a full-row overwrite.
+- The RPC-service task (`node/src/rpc_service/handler/bitvm_handler.rs:308-368`, `bridge_out_init_tag`) — a stale-read-then-full-row-`upsert_instance`, sets `Initialize` unconditionally as part of a full-row overwrite.
 - The GoatChain L2-event watcher (`node/src/scheduled_tasks/event_watch_task.rs:634-669,756-763,810-815`) — a 5-second tokio task, unconditional targeted `update_instance` on `SwapClaimEvent`/`SwapRefundEvent`, sets `Claim`/`Refund` with **no status precondition** (`InstanceUpdate`'s `WHERE` clause is only `hex(instance_id)=?` — confirmed via `crates/store/src/localdb.rs` that no `with_only_if_status_in`-style guard exists anywhere in the codebase for this entity).
 - The maintenance task (`node/src/scheduled_tasks/instance_maintenance_tasks.rs:482-517`, `instance_bridge_out_monitor`) — a 10-second tokio task, batch-reads a stale snapshot then per-row does an unconditional targeted `update_instance` to `Timeout` with no re-check at write time.
 

circuits/README.md

@@ -1,4 +1,4 @@
-# BitVM2 Circuits
+# BitVM Circuits
 
 ## Overview
 
@@ -203,7 +203,7 @@ RUST_LOG=info cargo run --package watchtower-proof --bin watchtower-proof -r --
 * Simutate a withdraw challenge
 
 ```bash
-cd crates/bitvm2-ga
+cd crates/bitvm-gc
 cargo test -r test_take2
 ```
 
@@ -251,4 +251,4 @@ input, while the dynamic public input is committed after the watchtower challeng
 * included-watchtower: a 256-bit bitmask; each bit flags a valid watchtower inside operator proof.
 * execution-layer-block-number: the block number that including `proceedWithdraw`(Peg-out) transaction of GOAT Network's execution layer(Geth).
 * watchtower-challenge-info: list of watchtower's challenge transaction id and compressed public key, i.e: [wachtower_info.json](./data/watchtower/watchtower_info.json).
-* watchtower-challenge-init-txid: the watchtower challenge init transaction id in GOAT's BitVM2 graph.
+* watchtower-challenge-init-txid: the watchtower challenge init transaction id in GOAT's BitVM graph.