0 sats \ 6 replies \ @DiedOnTitan 23 Feb \ on: Bitvm Crash Course by supertestnet - learn to build on bitvm through tic tac toe bitcoin
I commend the work you are doing with BitVM. You are no doubt learning a tremendous amount, so no matter the outcome of BitVM - whether it gains traction and succeeds or not, the knowledge you have gained will enrich you. That being said, BitVM fills the gap that certain OP codes, for lack of integration, leave open. Does it concern you that if e.g. OP_CAT eventually gets integrated into Bitcoin core, or other contenders like OP_SPLIT, OP_CSV, or OP_CHECKSIGFROMSTACK get baked in that BitVM will become moot?
Does it concern you that if e.g. OP_CAT eventually gets integrated into Bitcoin core, or other contenders like OP_SPLIT, OP_CSV, or OP_CHECKSIGFROMSTACK get baked in that BitVM will become moot?
On the contrary, that excites me. BitVM enables similar constructs to what those soft forks enable, only it's less efficient in terms of transaction size, and requires a 2 party Prover/Verifier setup, which sometimes creates additional trust assumptions. Fixing those inefficiencies sounds like a good thing so give me the soft forks please
reply
Nice. Some devs get attached to their work in a more clingy way.
How would you classify or name BitVM? Drivechain, sidechain? Something else?
reply
Nice. Some devs get attached to their work in a more clingy way.
Perhaps it helps that I am not paid to work on bitvm. If my income depended on bitvm's success I might be more irrationally attrached to it.
How would you classify or name BitVM? Drivechain, sidechain? Something else?
Bitvm is a suite of techniques which, together, allow one or more people to execute arbitrary computations on bitcoin, and one or more other people to penalize them for incorrect execution
So I suppose I would classify bitvm as a multiparty computation protocol
One plausible application of this protocol is to create a bridge to a sidechain. There are several ways to do it, and imo each bitvm-based bridge idea ought to have its own name, different from bitvm's name, on the principle that different things should have different names. One of my own ideas for a bitvm-based bridge is something I call unisob.
Besides sidechains, I also think bitvm is useful for some types of competitive peer to peer gaming (e.g. chess, lotteries, probably not Doom unfortunately) and for a type of covenant-substitute that I call bonded covenants.
reply
Well..Bitvm makes Bitcoin Turing complete, so Doom is technically possible? Just slow and likely very expensive.
reply
It's not so bad if one person is playing by themselves, e.g. in order to prove they didn't modify the software. And you could expand that to people competing for a high score on an unmodified copy of Doom. But a big problem arises when you give two people the controls and have them do a death match. Presumably, both will commit to reaching a state where the controls they input result in their character killing their opponent some number of times. Whoever does it first wins.
So then, what happens if a player, beginning to lose and not wanting to, abandons the game and challenges the remaining player to show what inputs they provided to reach the end state? The remaining player cannot prove that any inputs he provides "make it" to his committed end state, because as soon as either player quits, the next frame of the game cannot load. The game's state, in each frame, depends on both players revealing hashes for whatever buttons they are pressing or not pressing, and it cannot compute how the frame should look without that data -- from both players. Since the victim of this attack cannot prove he reached the end state, which he committed to reach, he cannot respond to the challenge created by the "sore loser," and will therefore lose his money when a timelock expires. So it basically turns into "whoever challenges first wins." Which is no fun at all.
This doesn't apply to a game like chess or tic tac toe, where there are a relatively small number of turns, and you can construct a set of bitcoin transactions that "passes the turn" back and forth. In Doom, both players provide inputs simultaneously, so you cannot pass it back and forth without modifying the game engine. You could probably modify it so that player 1 provides inputs on "even" frames and player 2 provides inputs on "odd" frames, and that would probably mostly work out decently if neither player abandons the game. But if either player does abandon the game, you have to take every remaining frame of the game to the blockchain, giving each player multiple blocks worth of time to figure out what buttons they should press given what they see on the screen. That makes the game effectively impossible to win. So I just don't think Doom deathmatches work.
reply
Thanks for the detailed reply. We will be sure to program only turn based RPGs on chain. :)
reply