anyone<\/em> to act as a verifier. It does not require someone to be a member involved in establishing the BitVM to challenge a dishonest prover. <\/p>\nThe fundamental shift here is moving away from directly using script NAND gates to implement the raw computational trace directly, and moving to using them to implement a general SNARK zero knowledge proof verifier (one of the core primitives Robin intended from the start to implement using BitVM). Instead of putting the raw input into the raw computational trace, and running it gate by gate in their own tapleaf scripts, the input of the BitVM 2 instance would simply be a zero knowledge proof input in combination with an asserted output of the computation. <\/p>\n
In addition to abstracting away the computation implementation with a ZKP, the tapleaf scripts are being massively expanded from a single NAND gate per leaf to an entire sub-function of the ZKP verifier. Instead of the challenge response protocol being based around the verifier guessing at which NAND gate the prover attempted to cheat at, selectively challenging at a single gate, the verifier can prove an entire sub-function\u2019s output is invalid according to the input. <\/p>\n
Just like BitVM 1, the contract is pre-negotiated using pre-signed transactions and branching scripts. Funds pegged into the BitVM are sent to an n-of-n multisig which signs two possible execution transactions, one in which no challenge occurs, and one in which a challenge occurs. To start the process of executing the contract, the prover initiates a kick off transaction. This kick off transaction commits to the output value \u2018y\u2019 they claim the computation produces, and includes three outputs: a timelocked output that is included in the no challenge execution transaction, a connector output A, and a connector output B, both of which also are spent in the no challenge transaction. <\/p>\n
Here is where the design allows for anyone to participate as a verifier. Connector output A has a second pre-signed transaction that can spend it, the challenge transaction. This is a pre-signed transaction that pays the prover a bond in bitcoin, but the connector output A is not enough to fund it. Literally anyone can add their own inputs to fund the transaction and spend connector output A, which invalidates the no challenge withdrawal transaction for the prover (one of the inputs it needs no challenge exists). <\/p>\n
This forces the challenge path. Connector output B is also spendable using a pre-signed transaction, the assert transaction, to the output of every sub-function in the entire BitVM 2 contract. This requires a large transaction with a lot of data, but remember, the ultimate output \u2018y\u2019 the prover is claiming the computation produced was already committed to in the kick off transaction. This creates two outputs. One is a timelocked output, the other is a connector output C. Both of these outputs, in addition to the original pegged in funds, are all spent in the second successful withdrawal transaction for the prover after the timelock. <\/p>\n
Connector output C is also spendable by anyone who can prove that any sub-function output in the BitVM 2 contract produces an invalid output. This requires a very large transaction, because the script necessary to prove an entire section of the BitVM computation is incorrect is massive, but in this single transaction a verifier can claim the coins in the connector output with a valid proof. This invalidates the second withdrawal transaction for the prover and effectively burns the coins. The only way to recover them at this point is if the prover and all<\/em> of the verifiers in the original n-of-n funding multisig all cooperate to recover them. Connector output B in the kick off transaction can also be spent after a much longer timeout than no challenge withdrawal to invalidate both the no challenge and the assert transaction, burning the pegged coins. <\/p>\nThis reduces what could be a ridiculous chain of transactions in the original BitVM proposal to enforce the correct contract outcome, to at most four transactions (although admittedly very massive ones), while in the process making the set of verifiers for the BitVM 2 instance literally anyone with bitcoin who will fund the challenge transaction. <\/p>\n
BitVM 2 could wind up being a significant breakthrough in regards to the wave of rollups and other layer 2s aiming to use BitVM as a two way peg. The operator of a rollup (the prover in the BitVM) can use their own funds to cover withdrawals of users who have pegged into the system, and periodically withdraw those funds from the BitVM to compensate themselves. Any<\/em> user or interested party would then be able to penalize them by burning their funds if they could produce proof the operator was not processing all withdrawals correctly. <\/p>\nIt is important to note that ultimately the security of a BitVM 2 instance is backstopped by the n-of-n keyholder, even though people not participating in it can still challenge the prover as a verifier. But because the prover has an efficient exit in the case of no challengers, and anyone can fund the challenge transaction to act as a verifier, the n-of-n funding multisig could follow a setup and key deletion ceremony similar to the Zcash launch to improve its security. <\/p>\n
BitVM 2 will probably wind up being a significant breakthrough in terms of improving the flexibility and trust model of two way pegs that make use of BitVM. Once again, Robin has proven himself a real wizard.\u00a0<\/p>","protected":false},"excerpt":{"rendered":"
Last October Robin Linus from Zerosync dropped a bit of a bomb in the form of BitVM. One of the longest running criticisms of Bitcoin is that it is not possible to make arbitrary programs to control how money is spent or locked. Bitcoin only has a very limited amount of programmability in its scripting […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-24545","post","type-post","status-publish","format-standard","hentry","category-crypto-news"],"_links":{"self":[{"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/posts\/24545","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/comments?post=24545"}],"version-history":[{"count":0,"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/posts\/24545\/revisions"}],"wp:attachment":[{"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/media?parent=24545"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/categories?post=24545"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoins-101.com\/wp-json\/wp\/v2\/tags?post=24545"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}