BitVM

The construction begins with a program that has been compiled into a circuit of binary gates. The two parties commit in advance to the values at every gate, and those commitments are placed in a Taproot script tree so that any single gate can be challenged individually. The commitments are made before the computation is run, which is what allows a later dispute to be resolved by inspecting one gate rather than the whole program.

When one party claims a result, the other can challenge it by pointing to a specific gate where the committed values are inconsistent. The challenge is resolved on-chain by a script that checks the gate, and the party shown to have committed a false value loses the funds at stake. The dispute is therefore narrow: it examines one gate, not the entire computation, which is what makes the on-chain cost bounded.

The construction relies on the ability to build a large Taproot script tree, which is covered on the Taproot page. The tree holds the commitments and the challenge scripts, and its structure is what allows a single branch to be revealed without exposing the rest.

The first limit is that the construction is two-party. It assumes a fixed counterparty who is willing to participate in the setup and to fund the challenge. A system that needs to work between parties who do not know each other in advance cannot use the construction as described, which restricts the applications it can support.

The second limit is the setup cost. Committing to every gate in a circuit requires a large script tree, and the size of the tree grows with the size of the computation. For a small program the cost is manageable; for a large one it is not, and the practical ceiling on the computation is set by what can be committed to rather than by what can be computed.

The third limit is that the construction requires the parties to be online and responsive during the challenge period. A party that disappears cannot be challenged, and the design has to account for that with timelocks and pre-signed transactions. Those mechanisms add complexity, and the complexity is where the remaining open questions sit. The proposal's own discussion acknowledges these limits rather than presenting the construction as a finished system.

What is specified is the construction itself: the compilation of a program into a gate circuit, the commitment to every gate value, the placement of those commitments in a Taproot script tree, and the challenge-and-response procedure that resolves a dispute by inspecting a single gate. The specification is complete enough to implement, and reference implementations and test vectors have been produced in the proposal process.

What is implemented is limited to that proposal work. BitVM is not a consensus change, it is not part of Bitcoin Core's consensus rules, and no node validates the computation. The construction uses Bitcoin's existing script rather than new rules, so what exists is prototype and research work rather than a system a user can rely on.

What is not deployed is therefore everything that depends on the construction: production bridges, two-party computation services and any other system that would use an on-chain challenge to settle an off-chain claim. The paper and its extensions remain proposals, and the page presents them as such rather than implying a timeline. A reader should treat every capability described here as proposed, not available.