Hot take: BitVM and Drive Chains
1131 sats \ 4 comments \ @03393ec3a3 14 Oct 2023 bitcoin
BitVM may obsolete the need for numerous soft forks to effectuate covenants and other utility.
Hot take: in the same way, a full BitVM implementation with a high-level programming language obsoletes Drive Chains. All of the benefits of Drive Chains - scalability, innovation design space and blast radius, risk reduction via air-gapped deployment, privacy via off-chain or potentially zk-compute, collaboration, customization, and increased L1 security - everything is subsumed by BitVM. Plus, all of these benefits can be achieved without L1 forks or merge mining tweaks.
Would anyone care to weigh in or offer to change my mind? Am I wrong? Anything I'm not considering?
write
preview
related posts
100 sats \ 0 replies \ @TheBTCManual 14 Oct 2023
Too early to tell how far BitVM can go, how much off-chain computation can reasonably be expected from two parties or if in future we have multiple parties, I get that this is an exciting avenue to pursue, I'm all for upgrades that don't mess with consensus, but I don't think BitVM is something that brings like an ETH type experience to Bitcoin, rather just expanding on the opcodes we do have and we'll see if people can build some cool functionality on top of it
reply
10 sats \ 2 replies \ @quark 14 Oct 2023
But BitVM will always be limited to the L1 capacity. Right?
reply
0 sats \ 1 reply \ @k00b 14 Oct 2023
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?
reply
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