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. 😂
Does a challenge tx script grow as the program grows? Or does it just represent a single bit in the program?
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.
have you looked into square and multiply?
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 am glad to see Vicky again, even though she ruins everything
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