BitVM: Compute Anything on Bitcoin

BitVM: Compute Anything on Bitcoin
2023-10-10  1:06 ` Lloyd Fournier
                   ` (4 more replies)
  
From: Robin Linus @ 2023-10-09 13:46 UTC (permalink / raw)
  To: bitcoin-dev

Abstract. BitVM is a computing paradigm to express Turing-complete Bitcoin contracts. This requires no changes to the network’s consensus rules. Rather than executing computations on Bitcoin, they are merely verified, similarly to optimistic rollups. A prover makes a claim that a given function evaluates for some particular inputs to some specific output. If that claim is false, then the verifier can perform a succinct fraud proof and punish the prover. Using this mechanism, any computable function can be verified on Bitcoin. Committing to a large program in a Taproot address requires significant amounts of off-chain computation and communication, however the resulting on-chain footprint is minimal. As long as both parties collaborate, they can perform arbitrarily complex, stateful off-chain computation, without leaving any trace in the chain. On-chain execution is required only in case of a dispute.

https://bitvm.org/bitvm.pdf

 permalink raw reply	[|nested]
2023-10-10  1:06 ` 
                   ` 
  
From: Robin Linus @ 2023-10-09 13:46 UTC (permalink / raw)
  To: bitcoin-dev

Abstract. BitVM is a computing paradigm to express Turing-complete Bitcoin contracts. This requires no changes to the network’s consensus rules. Rather than executing computations on Bitcoin, they are merely verified, similarly to optimistic rollups. A prover makes a claim that a given function evaluates for some particular inputs to some specific output. If that claim is false, then the verifier can perform a succinct fraud proof and punish the prover. Using this mechanism, any computable function can be verified on Bitcoin. Committing to a large program in a Taproot address requires significant amounts of off-chain computation and communication, however the resulting on-chain footprint is minimal. As long as both parties collaborate, they can perform arbitrarily complex, stateful off-chain computation, without leaving any trace in the chain. On-chain execution is required only in case of a dispute.

https://bitvm.org/bitvm.pdf

 permalink raw reply	[|nested]
* 
  2023-10-09 13:46 [bitcoin-dev] BitVM: Compute Anything on Bitcoin Robin Linus

  2023-10-10  1:12 ` 
                   ` 
  4 siblings, 0 replies; 6+ messages in thread
From: Lloyd Fournier @ 2023-10-10  1:06 UTC (permalink / raw)
  To: Robin Linus, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

Hi Robin,

Fascinating result.
Is it possible to give us an example of a protocol that uses BitVM that
couldn't otherwise be built? I'm guessing it's possible to exchange Bitcoin
to someone who can prove they know some input to a binary circuit that
gives some output.

Thanks!

LL

On Tue, 10 Oct 2023 at 01:05, Robin Linus via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Abstract. BitVM is a computing paradigm to express Turing-complete Bitcoin
> contracts. This requires no changes to the network’s consensus rules.
> Rather than executing computations on Bitcoin, they are merely verified,
> similarly to optimistic rollups. A prover makes a claim that a given
> function evaluates for some particular inputs to some specific output. If
> that claim is false, then the verifier can perform a succinct fraud proof
> and punish the prover. Using this mechanism, any computable function can be
> verified on Bitcoin. Committing to a large program in a Taproot address
> requires significant amounts of off-chain computation and communication,
> however the resulting on-chain footprint is minimal. As long as both
> parties collaborate, they can perform arbitrarily complex, stateful
> off-chain computation, without leaving any trace in the chain. On-chain
> execution is required only in case of a dispute.
>
> https://bitvm.org/bitvm.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2217 bytes --]

^ permalink raw reply	[|nested] 6+ messages in thread
* 
  2023-10-09 13:46 [bitcoin-dev] BitVM: Compute Anything on Bitcoin Robin Linus
  2023-10-10  1:06 ` Lloyd Fournier

  2023-10-10  1:27 ` 
                   ` 
  4 siblings, 0 replies; 6+ messages in thread
From: symphonicbtc @ 2023-10-10  1:12 UTC (permalink / raw)
  To: Robin Linus;  bitcoin-dev

Hello Robin,

I'm very interested in this development, as I've been longing for arbitrary smart contracts on bitcoin for a while. I've got a couple questions I'd like to ask, on behalf of myself and some others I've been discussing this with.

1. Do you have plans to implement a high-level language that can compile down to this or maybe adapt some existing VM to make these scripts? I'm sure many would love to get their hands on something a bit more workable to test this out.

2. What are the expected computational costs of establishing the tapleaves for these scripts? Is it feasible to do complex things like ECDSA signature checking, etc? I worry that the hardware required to use this tech will be a barrier in it's widespread use.

3. Would it be possible to implement existing zero-knowledge proof constructs on BitVM, and would that make verification simpler? I.e. instead of verifying your program directly with BitVM, have your program be written in some ZKP VM, and just have the proof verification execute on BitVM

4. What are the expected costs of resolving a fraud for a program? I assume this is quite nuanced and has to do with the exact circumstances of the program, but would it be possible for you to provide some examples of how this might go down for some simple programs to aid comprehension?

Thanks,
Symphonic

Sent with Proton Mail secure email.

------- Original Message -------
On Monday, October 9th, 2023 at 1:46 PM, Robin Linus via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:


> Abstract. BitVM is a computing paradigm to express Turing-complete Bitcoin contracts. This requires no changes to the network’s consensus rules. Rather than executing computations on Bitcoin, they are merely verified, similarly to optimistic rollups. A prover makes a claim that a given function evaluates for some particular inputs to some specific output. If that claim is false, then the verifier can perform a succinct fraud proof and punish the prover. Using this mechanism, any computable function can be verified on Bitcoin. Committing to a large program in a Taproot address requires significant amounts of off-chain computation and communication, however the resulting on-chain footprint is minimal. As long as both parties collaborate, they can perform arbitrarily complex, stateful off-chain computation, without leaving any trace in the chain. On-chain execution is required only in case of a dispute.
> 
> https://bitvm.org/bitvm.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


^ permalink raw reply	[|nested] 6+ messages in thread
2023-10-09 13:46 [bitcoin-dev] BitVM: Compute Anything on Bitcoin Robin Linus
                   ` (2 preceding siblings ...)
  2023-10-10  1:27 ` Anthony Towns

  2023-10-17 18:00 ` Russell O'Connor
  
From: ZmnSCPxj @ 2023-10-15 15:15 UTC (permalink / raw)
  To: Robin Linus;  bitcoin-dev

Good morning Robin et al,

It strikes me that it may be possible to Scriptless Script BitVM, replacing hashes and preimages with points and scalars.

For example, equivocation of bit commitments could be done by having the prover put a slashable fund behind a pubkey `P` (which is a point).
This slashable fund could be a 2-of-2 between prover and verifier `P && V`.

Then the prover provides a bit-0 point commitment `B`, which is a point.
If the prover wants to assert that this specific bit is 0, it has to provide `b` such that `B = b * G`.
If the prover wants to instead assert that this bit is 1, it has to provide `b + p` such that `B = b * G` and `P = p * G`.
If `b` (and therefore `B`) is chosen uniformly at random, if it makes exactly one of these assertions (that the bit is 0, or that the bit is 1) then it does not reveal `p`.
But if it equivocates and asserts both, it reveals `b` and `b + p` and the verifier can get the scalar `p`, which is also the private key behind `P` and thus can get the fund `P && V`.

To create a logic gate commitment, we have the prover and validator provide public keys for each input-possibility and each output-possibility, then use MuSig to combine them.
For example, suppose we have a NAND gate with inputs I, J and output K.
We have:

* `P[I=0]` and `V[I=0]`, which are the public keys to use if input I is 0.
* `P[I=1]` and `V[I=1]`, which are the public keys to use if input I is 1.
* ...similar for input `J` and output `K`.

In the actual SCRIPT, we take `MuSig(P[I=0], V[I=0])` etc.
For a SCRIPT to check what the value of `I` is, we would have something like:

```
OP_DUP <MuSig(P[I=1], V[I=1])> OP_CHECKSIG
OP_IF
  OP_DROP
  <1>
OP_ELSE
  <MuSig(P[I=0], V[I=0])> OP_CHECKSIGVERIFY
  <0>
OP_ENDIF
```

We would duplicate the above (with appropriate `OP_TOALTSTACK` and `OP_FROMALTSTACK`) for input `J` and output `K`, similar to Fig.2 in the paper.

The verifier then provides adaptor signatures, so that for `MuSig(P[I=1], V[I=1])` the prover can only complete the signature by revealing the `b + p` for `I`.
Similar for `MuSig(P[I=0], V[I=0])`, the verifier provides adaptor signatures so that the prover can only complete the signature by revealing the `b` for `I`.
And so on.
Thus, the prover can only execute the SCRIPT by revealing the correct commitments for `I`, `J`, and `K`, and any equivocation would reveal `p` and let the verifier slash the fund of `P`.

Providing the adaptor signatures replaces the "unlock" of the challenge-response phase, instead of requiring a preimage from the verifier.

The internal public key that hides the Taproot tree containing the above logic gate commitments could be `MuSig(P, V)` so that the verifier can stop and just take the funds by a single signature once it has learned `p` due to the prover equivocating.

Not really sure if this is super helpful or not.
Hashes are definitely less CPU to compute.

For example, would it be possible to have the Tapleaves be *just* the wires between NAND gates instead of NAND gates themselves?
So to prove a NAND gate operation with inputs `I` and `J` and output `K`, the prover would provide bit commitments `B` for `B[I]`, `B[J]`, and `B[K]`, and each tapleaf would be just the bit commitment SCRIPT for `I`, `J`, and `K`.
The prover would have to provide `I` and `J`, and commit to those, and then verifier would compute `K = ~(I & J)` and provide *only* the adaptor signature for `MuSig(P[K=<result>], V[K=<result>])`, but not the other side.

In that case, it may be possible to just collapse it down to `MuSig(P, V)` and have the verifier provide individual adaptor signatures.
For example, the verifier can first challenge the prover to commit to the value of `I` by providing two adaptor signatures for `MuSig(P, V)`, one for the scalar behind `B[I]` and the other for the scalar behind `B[I] + P`.
The prover completes one or the other, then the verifier moves on to `B[J]` and `B[J] + P`.
The prover completes one or the other, then the verifier now knows `I` and `J` and can compute the supposed output `K`, and provides only the adaptor signature for `MuSig(P, V)` for the scalar behind `B[K]` or `B[K] + P`, depending on whether `K` is 0 or 1.

That way, you only really actually need Schnorr signatures without having to use Tapleaves at all.
This would make BitVM completely invisible on the blockchain, even in a unilateral case where one of the prover or verifier stop responding.

Regards,
ZmnSCPxj


 permalink raw reply	[|nested]
2023-10-09 13:46 [bitcoin-dev] BitVM: Compute Anything on Bitcoin Robin Linus
                   ` (3 preceding siblings ...)
  2023-10-15 15:15 ` ZmnSCPxj

  
From: Russell O'Connor @ 2023-10-17 18:00 UTC ( / )
  To: Robin Linus, Bitcoin Protocol Discussion



While I haven't looked at the BitVM in detail, I would like to mention that
Simplicity's core language (excluding introspection primitives) has the
same expressivity as Boolean circuits.

A few years ago I did some experiments to compile Simplicity expressions to
a system of polynomial constraints (R1CS).  The experiments were
successful. For instance, I was able to compile our Sha256 compression
function specification written in Simplicity to a set of approximately
128,000 constraints.  Under this "circuit" interpretation, Simplicity types
represent cables, which are a bundle of wires equal to the 'bit size' of
the given type. The 'case' combinator ends up being the only "active"
component (implementing a demux).  The 'injr' and 'injr' combinators output
some fixed Boolean values. The rest of the combinations end up only
connecting, bundling and unbundling wires, and contribute no constraints at
all.

While my previous experiment was generating constraints, it is clear to me
that a similar interpretation could instead generate logic gates, and I
would expect the same order of magnitude in the number of gates generated
as the number of constraints generated above.  Thus Simplicity could be
used as a source of ready made expressions to generate useful circuits for
the BitVM, should someone be interested in pursuing this angle.

On Mon, Oct 9, 2023 at 10:05 AM Robin Linus via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Abstract. BitVM is a computing paradigm to express Turing-complete Bitcoin
> contracts. This requires no changes to the network’s consensus rules.
> Rather than executing computations on Bitcoin, they are merely verified,
> similarly to optimistic rollups. A prover makes a claim that a given
> function evaluates for some particular inputs to some specific output. If
> that claim is false, then the verifier can perform a succinct fraud proof
> and punish the prover. Using this mechanism, any computable function can be
> verified on Bitcoin. Committing to a large program in a Taproot address
> requires significant amounts of off-chain computation and communication,
> however the resulting on-chain footprint is minimal. As long as both
> parties collaborate, they can perform arbitrarily complex, stateful
> off-chain computation, without leaving any trace in the chain. On-chain
> execution is required only in case of a dispute.
>
> https://bitvm.org/bitvm.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>