pull down to refresh
141 sats \ 5 replies \ @supertestnet 25 Oct 2023 \ on: Question about Bitcoin smart contracts: BitVM vs. RGB bitcoin
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.
Good!
reply
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
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
Super-clear, thanks for the explanation!
reply
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