pull down to refresh

0 sats \ 1 reply \ @k00b 14 Oct 2023 \ parent \ on: Hot take: BitVM and Drive Chains bitcoin
To some extent, but I suspect the onchain footprint isn't larger than typical transactions in the cooperative case nor very large in the uncooperative case which I'm guessing scales as log(n) where n is the number NAND gates in the circuit.
@supertestnet is this accurate?
write
preview
5926 sats \ 0 replies \ @supertestnet 14 Oct 2023
the onchain footprint isn't larger than typical transactions in the cooperative case
Correct. Also, the cooperative case can involve many off-chain computations, including off-chain transactions, e.g. on a rollup (if we can figure out how to do that). So it could even free up capacity on the base layer.
the uncooperative case which I'm guessing scales as log(n) where n is the number NAND gates in the circuit
  1. According to Robin the uncooperative case can be made to scale as log(n). I am skeptical of this because I don't understand how it works. My implementation does not scale in the uncooperative case -- the entire computation must be dumped on chain in my implementation because I don't understand Robin's solution here.
  2. Just a reminder: we're not limited to NAND gates. They were just an example used in the whitepaper to save space, since it's well-known that if you can do NAND, you can do anything (inefficiently). We can use all of the standard logic gates (AND, OR, NOT, NAND, NOR, XOR, XNOR) plus perhaps some of bitcoin's built-in opcodes. My implementation does not even use NAND -- it uses AND, NOT, and XOR.
reply