BitVM: But Can It Run DOOM?

Shinobi’s Strawman is a weekly series where our Technical Editor Shinobi challenges the Bitcoin community, aiming to stir up conversation around heated technical debates.
Shinobi’s Strawman is a weekly series where our Technical Editor Shinobi challenges the Bitcoin community, aiming to stir up conversation around heated technical debates.

Shinobi’s Strawman is a weekly series where our Technical Editor Shinobi challenges the Bitcoin community, aiming to stir up conversation around heated technical debates.

______________________________________________________________

So, some complete autist who is a relative newcomer to the public arena had to just come out of absolutely nowhere and drop a crazy idea onto the table that we can do right now with no changes or forks to Bitcoin at all, didn't they?

How Bitcoin of you Robin. (Readers should probably at least give the article above a try and see if it helps your understanding of BitVM before going forward)

While I do think a lot of the excitement over the idea is getting very overblown and disconnected from the reality of it, I do still think this is a monumental moment in Bitcoin history. The efficiency level of building things on BitVM in terms of the size of taproot trees needed and the number of pre-signed transactions required is absolutely abysmal, and at least to me it's a very open question what types of use-cases would actually find that level of inefficiency an acceptable trade-off for the guarantees it provides, but the possible functionality that can be achieved is enormous.

Already two concrete ideas have been put forward that, despite the massive off-chain cost in pre-signed transactions and scripts for inside the taptree, might actually make sense to pay that data cost to get the types of trust guarantees BitVM can provide.

First, a new type of two way peg, a "Sentry peg." A federated sidechain could be set up where the federation puts a bond into a BitVM contract enforcing the logic of a sidechain. Then, whenever they process a withdrawal, they would have to feed a proof into the BitVM proving it is a legitimate withdrawal. If they don't, a set of verifiers functioning as watchtowers could confiscate the federations bond in the BitVM. It offers an interesting possibility in having a dynamic where the entity custodying funds on the sidechain has to actually prove to an external party that they are acting correctly or have funds taken. The new dynamic here versus traditional slashable bond schemes is that the logic arbitrating when slashing occurs can be much more complex, and is actually verified in enforcement rather than through cute cryptographic tricks or another layer of trust.

Second, UTXOracle. While a very awesome way to calculate the price of Bitcoin in dollars trustlessly with your own node, there wasn't any way to actually get that data "into" a Bitcoin script in any way to use it trustlessly in a smart contract. BitVM offers a way to do that. Constructing a logic gate circuit to SPV verify a Bitcoin block (just the proof of work), actual full blocks could be fed into a BitVM and with a long enough string of them you could actually use the UTXOracle logic inside the BitVM, tying the outcome of the contract to that price data derived trustlessly from the blockchain.

For high value contracts or sidechains, that could be worth a few hundred megabytes, or even a gigabyte or two, of off-chain data for the assurances it provides. Overall, while BitVM isn't magically going to turn Bitcoin into Ethereum overnight, and progress will likely be very slow and experimental, it does open the door to a whole new paradigm of how to use Bitcoin.

So, just like last time, please send in your thoughts, questions you have to help clarify your understanding of BitVM, or ideas on what can actually be done with this. My DMs are open, and [email protected] is another option. Next week I'll go through everything and hopefully we all come out with a better understanding of the proposal.

Until next week.