Repository navigation
Conversation
added 5 commits
November 9, 2026 13:58
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on #527. Review against
audit/29-force-skip-committee; merge the parent first, then retarget this PR todev. goat is copied from GOATNetwork/BitVMgc-v2at 2c76a2c, the head of GOATNetwork/BitVM#23, so it already contains the M29 connector change. After this lands, Cargo no longer points at a BitVM PR branch.goat (the transaction graph, connectors and scripts) had no user other than this node, and every change to it needed a BitVM PR plus a Cargo branch switch here. The
bitvmcrate (BitVM's script and signature library) now comes from upstream BitVM/BitVM, pinned to one commit that node and GOATNetwork/bitvm-gc share. Nothing depends on GOATNetwork/BitVM any more.Commits, each reviewable on its own:
crates/goat/srcis byte-identical togoat/srcat 2c76a2c (check withdiff -r). The manifest keeps the dependency specs the BitVM workspace gave goat, and the lockfile only swaps goat's git source for the path. MIT license file included.-D warnings:&Vecparameters become slices, onesaturating_sub,#[allow(clippy::too_many_arguments)]on three constructors, two test arrays. Callers are unchanged apart from one bitvm-gc test.proof,common,serializationand thetx-senderbinary, none of which is used. The groth16 proof tests read files that do not exist. goat's dependencies go from 36 to 14.bitvmfrom branchgc-v2and bitvm-gc from branchGA, so Cargo built it twice.bitvm/is identical on both branches. Node and bitvm-gc (refactor: pin BitVM to a shared commit bitvm-gc#61) now both userev = "26b0bd61b61b24b50b2d2443a7fda8e58412edfa"(GA), and node pins bitvm-gc by rev as well. The fmt job fails if Cargo.lock holds more than onebitvm.rev = "c620dbfaacebdf778e765a6681985350389973b1"(main, 2026-10-21). GOATNetwork/BitVM's own changes tobitvm/are all inchunk/(the groth16 verifier:NUM_PUBS = 2, the*_lithelpers), which nothing here uses. The modules we use (signatures,hash::blake3,execute_script,treepp,RawWitness) are identical to GA apart from a re-enabled test. Upstream's one functional change since, the zero-bitlshift_prevent_overflow, is called only frombn254. So scripts, WOTS encoding and connector addresses do not change.Review notes
crates/clientnow declares the same reqwest 0.11 features so the backend does not change. With that pin, the node binary's resolved features are identical before and after, apart from the unused toml 0.5. proof-builder-rpc gains only reqwest'sblockingmodule, which it does not call.gc-v2can be frozen.main.Tests: goat's 13 tests now run in node CI. bitvm-gc, node tests, workspace clippy with
-D warningsand fmt pass. The node binaries' resolved features are identical before and after the bitvm pin and the upstream switch. bitvm-gc: verifiable-circuit-babe and soldering-host build against upstream bitvm, and its WOTS tests pass.Validation results above are recorded in the zkm PR notes. The final dependency URLs and revisions were checked against the current PR head; builds and tests were not rerun during this description update.