Hi guys, from one of my previous posts I have the impression that many of you are interested in technical Bitcoin-related topics, but maybe find it hard to understand their core concepts or to find good sources.
So here I am with another question, this time about smart contracting on Bitcoin.
A few days ago, I started reading stuff about BitVM and how it could open a lot of possibilities for the future of bitcoin (great starting document here: https://github.com/twhit223/bitvm_primer). When I first looked at it, it instantly came to my mind the RGB protocol, which was also supposed to enable Turing-complete calculations on Bitcoin.
Sorry to abuse of your patience (again), but is there anyone kind and knowledgeable enough to illustrate the main differences between BitVM and RGB, commenting on what might be the most promising for the future and for which specific use cases?
Also, how do BitVM and RGB relate to Discreet Log Contracts (DLCs) and HTLC, aren't these also other forms of smart contracting on Bitcoin?
Sorry for the confusion, but I keep reading about a lot of interesting concepts and I would really like to know more :)
Thanks!
141 sats \ 5 replies \ @supertestnet 25 Oct 2023
RGB uses a virtual machine called AluVM which can only operate on RGB tokens, not on btc directly. To make it work with bitcoin, they need a bridge to "wrap" bitcoin in an RGB token, and their current proposal (Radiant) relies on pledging a separate token (e.g. Tether) as collateral so that if a "wrapped bitcoin" issuer doesn't let you take your bitcoins back at their original value, the issuer loses their collateral. (Note that the actual amount you would receive back would be plus or minus any gains or losses you may have incurred while using RGB, and also minus a fee for the "wrapped bitcoin" issuer.)
BitVM works on bitcoin directly. There is no need for bridging, collateral, a separate token, or an issuer. Two people just put bitcoin in a bitvm address that contains a program, and the program decides which person gets that money. Both parties run the program off chain to determine this, and if there is a dispute, either one can force the correct result by running a small part of the computation on the blockchain.
Both virtual machines (BitVM and AluVM) are equally powerful in theory (i.e. both can run any computable function) but AluVM has three advantages: it has better developer tools (because it's been in the works for longer), there are already some cool contacts written for it that anyone can play with today, and it doesn't require two people to hold each other accountable, as bitvm does. Bitvm's advantages, by contrast, are already mentioned: it works on bitcoin directly, with no need for bridging, collateral, a separate token, or an issuer.
reply
1 sat \ 0 replies \ @Rsync25 25 Oct 2023
Good!
reply
1 sat \ 2 replies \ @MattInTech OP 25 Oct 2023
From what you wrote there seem to be quite a lot of overlap between BitVM and Discreet Log Contracts, but those are not based on native Turing-completeness afaik. Is that correct?
reply
52 sats \ 1 reply \ @supertestnet 25 Oct 2023
Yes, that is correct. Discreet Log Contacts and BitVM both involve two people putting money in a bitcoin address and running a program off chain to determine who should get the money. The only meaningful difference in my opinion is what happens if there is a dispute.
In a DLC, if there is a dispute about the outcome, the victim can use some data published by an oracle (a trusted third party) that both parties agreed to use before they put their money in the bitcoin address. The oracle independently ran the same program the two parties agreed should determine who gets the money, and the result published by the oracle breaks the tie, resolving the dispute.
By contrast, when there is a dispute in bitvm, no oracle is used, instead a small part of the program is run directly on bitcoin's blockchain. The victim finds one part of the program which they claim the other party ran incorrectly. Bitcoin itself can check which party ran that part of the program correctly, thus identifying the victim and giving them the money.
reply
1 sat \ 0 replies \ @MattInTech OP 25 Oct 2023
Super-clear, thanks for the explanation!
reply
0 sats \ 0 replies \ @anon 25 Oct 2023
Well, talking about bitcoin original value is kinda pointless as what you receive is actually an rgbBTC token backed by real BTC stored in a multisig, so when you peg-in 1 BTC, you get 1 rgbBTC (minus fees), and peg-out 1 rgbBTC -> 1 BTC.
With this in mind there is no way how you can end up with "any gains/losses while using rgbBTC", the only way rgbBTC is minted is through the peg-in process, so amount of rgbBTC tokens in circulation is always equal to the amount of tokens held at the multisig/multisigs owned by rgbBTC issuers. You can of course transfer tokens to other party, and then you can only peg-out the portion you still own (with the remainder redeemable by the other party).
Like you wrote - rgbBTC issuers (multisig participants) are incentivized to behave honestly by having to post a stake/bond in an RGB token that can be slashed in case they misbehave.
We were also thinking in the direction of using BitVM and having the stake/bond be in native BTC. Imagine you have 2/3 threshold multisig wallet, where every participant has to deposit e.g. 1 BTC in stake/bond, this 1 BTC bond is locked up in a BitVM between him and 2/3 supermajority of other stakers. In case that any staker misbehaves, the supermajority can slash his stake/bond by proving his action in BitVM. The advantage of this is that the staking/backing token is bitcoin and therefore you are not exposed to price volatility risk, or counterparty risk (like what would be the case with USDT). The disadvantage being that you need a supermajority of stakers to slash a staker.
reply
21 sats \ 3 replies \ @nerd2ninja 25 Oct 2023
My surface level understanding of RGB is that it has a sustainability problem, wherein smart contracts are more difficult to validate over time and at a certain point you'll try to send someone something on RGB and they will have to spend like a year or something undesirable verifying it in order to receive it.
BitVM on the other hand (and again I haven't done the deep dive on it, although with BitVM I kinda want to dive into at least a little bit) will actually resolve on the main global state chain when the program is complete and then you can launch a new program from there. So it seems more sustainable although I'm sure you could make it in a way that one party is able to verify faster than the other party could catch up or something idk like I said I want to delve into it more.
reply
50 sats \ 2 replies \ @anon 25 Oct 2023
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? :)
reply
1000 sats \ 1 reply \ @nerd2ninja 26 Oct 2023
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
0 sats \ 0 replies \ @anon 26 Oct 2023
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
1000 sats \ 0 replies \ @Rsync25 25 Oct 2023
BitVM = computer on-chain and off-chain use Taproot natively = good for create complex multisig and potential trustless sidechains
RGB = computer on Bitcoin use Client Side Validation and AluVM = compatible with DLCs and HTLCs for DEX, stablecoins backed by Bitcoin.
reply