pull down to refresh
50 sats \ 2 replies \ @anon 25 Oct 2023 \ parent \ on: Question about Bitcoin smart contracts: BitVM vs. RGB bitcoin
One can say that about bitcoin blockchain as well ;)
Bitcoin has a sustainability problem, where blockchain is more difficult to validate over time, and at a certain point you'll need to spend weeks verifying it (already happening e.g. on raspberry).
Why is that the case? Because everyone has to verify everything for everyone.
The point is, RGB state transitions (e.g. asset transfers) scale strictly better than any blockchain, since you only have to verify history of that specific asset you are receiving and only transactions that you care about (the ones leading from genesis to you). Also, you can use zk proofs to compress the history to a few kB (with SNARKs) or tens of kB (with STARKs) - this is of course something a few years down the line.
Just for comparison, one RGB asset transfer adds around 200 bytes of data to the history, and again, you don't verify ALL asset transfers for an RGB contract, ONLY small subset of those (leading from the contract genesis to you). We will have several years before that starts becoming an issue and by that time we should have zk proof history compression in place.
One more point: RGB asset transactions on lightning don't grow the historical data at all - only funding tx and closing tx is counted towards it (as those are only 2 txns actually committed on the blockchain), so opening and closing a lightning channels incurs just 400 bytes of history data in total, with hundreds of thousands transactions that could be done over that lightning channel, magical lightning, isn't it? :)
Fuck....I just zapped an anon account...lmao
Uh anyway that sounds great lol. No, its just like I said I only have a very surface level understanding and that surface level understanding makes BitVM sound like a better option, but you're absolutely right about our append only timechain, but that is why we constrain it to only what's absolutely necessary so that we reduce how bad it'll be by as much as we can.
reply
Indeed, so in that case BitVM actually doesn't sound like a better option, since that requires 2*log2(#of_compute_steps) on-chain bitcoin transactions in case of dispute, each transaction possibly ~400vB.
RGB on the other hand, only commits (stores a hash) the off-chain data into bitcoin transactions and does so in the tapscript hidden under taproot address (something we call tapret - OP_RETURN hidden inside of taproot tree). So you can have 1-in 1-out 110vB bitcoin transaction that commits to an off-chain state transition (without using any more data on the bitcoin blockchain - also invisible to chainanal). Even better, you can actually commit to multiple state transitions in a single transaction, so you can do hundreds of RGB token transfers that are committed to single bitcoin transaction of just 110vB (that's what RGB guys mean with scalability). So bitcoin blockchain pollution is super low.
All of the raw state transition data is accumulated only in the off-chain history of the RGB contract, and that's where this 200 bytes per transaction grow is, but again, you only verify a small subset of all those transactions.
In the end, BitVM and RGB are 2 completely different things.
BitVM is good for verifiable off-chain computation in a 1-to-1 channel (like lightning).
With RGB you can create off-chain contracts (tokens, NFTs, digital revokable identity, verifiable audit log - like opentimestamps), that are bound to UTXO - so they are composable with everything a normal bitcoin UTXO is composable with - HTLCs, adaptor signatures, DLCs, PTLCs, multisigs.
You can even use BitVM with RGB assets instead of bitcoin!
reply