Here is my explainer from twitter:
In bitvm, the prover must unlock one of two hashlocks to set a bit to 0 or 1. He does that for every bit in the program, and medium sized programs have millions of bits. Zman says we can use pubkeys instead of hashlocks.
The prover would set a bit to 0 or 1 by revealing the private key to one of two pubkeys. If he wanted to set a bit to both 1 AND 0 (i.e. if he tried to write bad code) he would have to reveal both private keys, and the verifier could take his money.
The incentive to be honest right now is, a dishonest prover loses money. Zman's proposal doesn't change that, but it makes a new tradeoff: the contracts wouldn't be so massive, but now Paul can't just "send" the contract to Vicky, they have to create it -- bit by bit -- together.
Zman proposal's also lets us use schnorr tricks to "combine" multiple public keys, which would save space and make bitvm much more efficient. A drawback is that schnorr tricks require interactivity -- Paul and Vicky have to define each bit together, which is difficult to do.
Two designs are possible for really big programs: Robin's design has really big contracts. It's not hard to create them but it could cost a lot for both parties if there is a dispute. Zman's design has really small contracts that cost less. But they are much harder to create.
As with many things in bitcoin, there are tradeoffs that developers have to pick from. Do they make contracts that are easy to produce but costly to dispute? (That's Robin's model) Or hard to produce but cheap to dispute? (That's Zman's model)
As a reminder, I have a proof of concept implementation of bitvm and it follows the "easy to produce / costly to dispute" model. But right now it doesn't support large programs anyway, so the "costly" part doesn't apply (it only applies to large programs): https://supertestnet.github.io/tapleaf-circuits/
reply
I have been toying with the idea of something similar to this for a while using DLCs. You can raise the stakes by making a double-spend burn an xpub versus one key.
reply