pull down to refresh

Alrighty so what are SN reactions/feelings about this???
Their whitepaper is pretty bad at explaining what this tech is, and their docs aren't much better. I'll give it my best shot but if anyone from sovryn is reading, please correct me if i'm wrong here.
The whitepaper introduces two technologies, "Grail" and "BitSNARK", which i assume taken together are the 'framework' they call BitcoinOS.
They claim BitSNARK is a more efficient version of BitVM for the specific case of validating ZK rollups, but they fail to elaborate on how they made it more efficient and how it works internally, beyond the high level overview given on page 3. The main raison d'etre of BitSNARK seems to be to act as an on-chain enforcement mechanism for settling smart contract disputes using zero knowledge proofs (Groth16 snarks) as the ultimate source of truth for who 'wins' the settlement. Basically this is BitVM specifically instantiated for SNARK verification.
Also, Groth16 requires a per-circuit trusted setup and produces "toxic waste", and their paper doesn't clarify how they deal with that. Who does the trust fall on? What are the consequences if the trusted parties misbehave and keep their toxic waste?
As for Grail, it seems to be a procedure used to 'transfer' bitcoin in and out of an L2/sidechain, using BitSNARK (BitVM+ZKP). This type of procedure seems to be a hot topic for businesses these days. Full disclosure: i'm doing some work for a company who is building something similar, except with multisig escrow instead of an on-chain ZKP verifier.
Grail Bridge
The bridge is intended to allow users to transfer assets between the Bitcoin blockchain and an L2 (Layer 2) network
Operators can lock funds on the Bitcoin side by sending them to Taproot addresses created using BitSNARK. The funds are thereby locked in a UTXO until a SNARK proof is provided that allows them to be retrieved. On the L2 side, the operator sends a SNARK proof to the bridge smart contract, thereby causing the bridge to mint tokens to the operator’s wallet. In the reverse process, an operator burns their tokens via the smart contract, thereby obtaining a SNARK proof that allows the operator to retrieve their funds, on the Bitcoin side, from the UTXO, using the BitSNARK protocol.
So the "Unlimited Smart Contracts and Scalability" claim they have emblazoned on their website isn't occurring on bitcoin - it's occurring off-chain, and the framework they've designed is just an engine (powered by BitVM and SNARKs) to allow people to wrap bitcoin which they can then use on smart contracts inside the given L2.
Ultimately users still need to choose their L2 wisely because a bug or hack in the L2 will destroy the wrapped bitcoins, and prevent users from creating valid proofs to reclaim the actual Bitcoins proper.
For example, if you used Grail to wrap BTC onto Ethereum, and then deposited that wrapped-BTC in a poorly coded ETH smart contract which gets hacked, then you're shit-outta-luck - the hacker can burn the wrapped-BTC and create a proof which lets them sweep away your mainchain BTC, and you can't do anything about it. Your money would be just as gone as if you'd just sent your BTC straight to the hacker in the first place.

Overall rating: 6/10. Highly efficient ZKPs enforced on Bitcoin is exciting and I would like to know more about how their 'BitSNARK' system actually works. I think Sovryn is focusing on the wrong use case with Grail though. Instead of bridging Bitcoin to shitcoins, they should be focusing on using BitSNARK to create more powerful expressive tools on L1 bitcoin.
reply
100 sats \ 1 reply \ @Cje95 OP 26 Jul
Thank you for this fantastic breakdown! I have a couple of questions if you are able to clarify some things with this I'd appreciate it! What is toxic waste in the way you are mentioning it and what does it do? Also, could you explain a little what the difference is between a multisig escrow instead of an on-chain ZKP verifier?
Thanks in advance!
reply
Many Zero-knowledge proving systems, including Groth16, require something called a 'trusted setup ceremony', where one or more people (usually a commonly trusted set of third parties) create some secret data and some corresponding public data. The public data from this ceremony can then be used to create and verify zero knowledge proofs. The important part of the ceremony is that the secret data (often called 'toxic waste') must be deleted unrecoverably.
If that toxic waste isn't deleted, it can be used to create fraudulent proofs indistinguishable from valid proofs.
There are more powerful ZKP systems like STARKs available these days, which do not require trusted third parties, but their proofs are much larger and slower to verify. Most blockchain applications prefer SNARKs for performance.
Also, could you explain a little what the difference is between a multisig escrow instead of an on-chain ZKP verifier?
Sovryn's on-chain ZKP verifier is basically a BitVM smart contract holding a user's BTC in escrow, which says: "release these coins to whomever can provide a proof that X tokens were burned on Y other blockchain". How that proof is constructed I don't know... But if such a proof can be verified on Bitcoin (using their flavor of BitVM) then the prover is entitled to get their escrowed bitcoin back.
A multisig escrow is much simpler, faster, and more efficient on-chain, but requires more trust. A user deposits money into a 2-of-2 multisig, where the first key belongs to the user, and the second key is a FROST threshold key belonging to some group of independent auditors. Those auditors watch the other blockchain and promise to sign a refund transaction when the user burns their wrapped BTC tokens.
Naturally the auditors could withhold that signature, or go offline, and the user doesn't get their money back. Hence the higher trust level. But with a diverse enough group, that risk can be mitigated, and there's zero risk of the user's Bitcoins being stolen because the user holds one of the necessary signing keys.
reply
Surprised that this is not getting more traction after 21 hours. If I understand this correctly, BitcoinOS effectively enables covenants, and other functionality without requiring soft forks of any kind. This is rather a significant achievement if it holds water. This means that good old stable Bitcoin can remain unchanged, solid, and "boring" while also allowing all the flexibility of smart contracts, ZKPs, and the unlimited scalability of any shitcoin ever proposed. Effective implementation of this should drain the liquidity from all other alts and help confirm the thesis that the world only needs one blockchain with Bitcoin crowned the undisputed king.
Before I get too far ahead of myself, I would value @supertestnet's take on this development. I know he worked on BitVM which BitcoinOS specifically mentioned influenced it.
reply
If I understand this correctly, BitcoinOS effectively enables covenants
The BitcoinOS people are active in the bitvm telegram, which I am also active in. BitcoinOS is based on bitvm (it's a new, customized implementation of the same basic idea) and it inherits one of bitvm's limitations: at least one member of a predetermined group needs to be trusted to execute BitcoinOS honestly. (The group can be very large, e.g. it can have 900 people in it.) If that assumption holds, then yes, you get covenants, and not just covenants, but any other soft fork or sidechain or spending condition anyone wants. That's pretty massive and extremely cool to me.
But you could definitely argue that these aren't "real" covenants because if all 900 (or so) people agree to break the covenant together, they can do so, and a "real" covenant (the soft fork kind) cannot be broken. If a "real" covenant says "these coins can only go to Pubkey X" then that's the only place they can go. If a 900-of-900 multisig signs a transaction saying "these coins can only go to Pubkey X, and if we break that promise you can penalize us using BitcoinOS" -- well, that's not a "real" covenant because they can still break their promise and face the penalty. BitcoinOS "covenants" are breakable (and therefore, technically, not "real" covenants) because BitcoinOS has an additional trust assumption beyond bitcoin's standard trust assumptions -- sometimes it's called the "single honest party" trust assumption.
Even though they've reduced that trust assumption to something like "it works as long as one person in a group of 900 people is honest," that's still a bridge too far for some people. But that's great! They can just not use it, so it's a win-win imo. I personally want to find solutions with a 0-honest-party trust assumption. But I'm happy that 1-out-of-900 (or similar) gets us pretty close to that, and lots of cool stuff can be built on top of that, even though it's not all the way there yet. And, well, you know, nothing's perfect anyway.
reply
at least one member of a predetermined group needs to be trusted to execute BitcoinOS honestly.
This is very clarifying. Thanks for the detailed response. This does indeed feel like a great step in the right direction.
reply
Realistically how close are we to real covenants then? This was the first time I had ever heard of them and was instantly fascinated by the idea because of what I feel they could unlock! Or are they something that really likely will never come to fruition for either technological or use case issues?
reply
Yeah Im not gunna lie I was surprised it didnt gain more traction either! It doesn't require a hard fork I did get a little confused if it would need a soft fork or not but none the less it is a remarkable advance in tech! Esp this section
ZKPs can be used to create covenants—conditional payments that cannot be executed unless the right proof is provided. This is the key to building a decentralized Bitcoin bridge
reply
What functionality is being discussed here? I hope this has nothing to do with shitcoins.
The achievement unlocks unlimited scaling and functionality on Bitcoin without requiring additional changes to Bitcoin’s base layer.
reply
So much like the L2's in Ethereum the idea is to allow for faster, cheaper, and more programmable transactions. In theory, this could allow for shitcoins to be deployed in the future if someone works to develop the tech in this way but it purpose is not to do that.
In its live presentation, BitcoinOS said it will show that ZKPs can be used to create covenants—conditional payments that cannot be executed unless the right proof is provided.
reply