pull down to refresh
100 sats \ 0 replies \ @Car 14 Feb freebie
Wow this is great Super! 👏👏👏 Your presentations are getting so much better. Also your able to really simplify high level concepts, so well now.
reply
0 sats \ 0 replies \ @0xIlmari 14 Feb
Inb4 they make a new breed of shitcoins based on that and Luke calls it an exploit.
reply
0 sats \ 1 reply \ @BITC0IN 14 Feb
does this make covenant proposals moot?
reply
1 sat \ 0 replies \ @supertestnet OP 14 Feb
At 8:43 I talk about the difference between "bonded covenants" (which bitvm gives us) and "real covenants." The short version is, bonded covenants aren't as good as real covenants because they introduce an additional trust assumption, but they are probably a "close enough" substitute for real covenants in many contexts. IMO the real thing would still be better.
At 10:57 I also talk about how if we had real covenants we could improve bitvm's trust assumptions in cases where you aren't part of the contract. Bitvm follows trust assumptions similar to the lightning network if you have a direct bitvm contract with the prover. But if you don't, you have to trust someone who does. With real covenants, we could improve bitvm so that it works well without the need for a direct contract with the prover. See the video for more details.
reply
0 sats \ 1 reply \ @DiedOnTitan 14 Feb
This is interesting indeed. Seems like with such operations it comes a step closer to making Bitcoin Turing complete? Might have some unintended consequences...
reply
412 sats \ 0 replies \ @supertestnet OP 14 Feb
Yes. By leveraging tapleaves and passing state through multiple transactions we can indeed run vastly complex programs on bitcoin. But it is better to run them offline and just use bitcoin if there's a dispute because running a complex program on bitcoin costs a lot of money and requires dozens of transactions.
reply
0 sats \ 1 reply \ @BlueSlime 14 Feb
Wonderful talk, bit lengthy but you take the time to explain everything in great detail. I feel it gave me a solid understanding of a bitvm transaction and how it works.
Some questions:
Does a challenge tx script grow as the program grows? Or does it just represent a single bit in the program?
Also, have you looked into square and multiply? It could open up key tweaking within a bitvm program, which would be pretty rad.
I am glad to see Vicky again, even though she ruins everything. 😂
reply
412 sats \ 0 replies \ @supertestnet OP 14 Feb
It depends on how you write it. In my version, every tapleaf commits to a single logic gate and they are all nearly identical in size, except for OP_NOT (also known as an INVERT gate) and OP_LID (also known as a BUFFER gate), which are considerably smaller than the other logic gates because they only have one input and one output, which means they only have two input hashlocks rather than four.
However, Robin's model relies on a very different architecture than mine. One reason why is that he tries to do as much "work" in each tapleaf as he can so that bisection happens in fewer transactions. Consequently, his version is more efficient than mine.
The 8 bit cpu I wrote for bitvm can square and multiply any 8 bit number and keep track of overflows. Robin's version has a 32 bit cpu that can do the same on 32 bit numbers. I don't think we are far from being able to do key tweaking.
I was too harsh on Vicky, she is a wonderful and integral part of making bitvm work. Still, I'd like to eliminate the role of the verifier someday because bitvm would have better trust assumptions if Paul was "unable" to be dishonest rather than just "it's expensive to be dishonest if Vicky catches you."
reply