This is an attempt to develop a better version of ideas RGB and Taro. There's a perception amongst many that these kind of protocols are useful only for gambling on tokens, and not helpful to BTC, but I have disagreed on that before, and still do.

The root idea came from Peter Todd many many years ago, namely this nuance: blockchains are only needed for double spend prevention, not for consensus on what is and is not a valid coin. Hence the content of transactions can be garbled junk to everyone except the spender and the receiver. While there's a ton of stuff to figure out before that can actually work, it's obvious what the advantage is, and it's huge: transactions are more private, and (a twist on the usual way of looking at it): the computational burden of validation is reduced for nodes, which is actually very *healthy* for the base p2p bitcoin network!

On that "ton of stuff": that's exactly what RGB and then Taro worked on for several years; this new paper claims (I suspect correctly, but there's some details to work out) to have made a better version. The principal advantage is compactifying the validity proof of a coin that you're receiving from being the size of your coin's history, to being a constant, small size (asymptotically down to 64 bytes). But it seems like the exact details have not been worked out; they don't yet have working code, for example.

So finally, is this "just for gambling on tokens" and not for exchanging BTC? Kinda yes, kinda no. As the paper points out in an Appendix, you can definitely create a proper (trustless) atomic swap construct for exchanging (whatever token is in your Shielded CSV "account") to BTC and back. You could also do this with e.g. the Liquid sidechain, though at least there you don't have currency exchange risk in doing so. I don't know if it might be possible to create a 's-csv-btc' token in this system and then 'sideswap' like that, i *guess* so? How stable is the "peg" if there is no unilateral exit, only swaps? .... it would be very attractive if it all worked as planned, since you would have *very* private transactions with ~ immediate transfer and very small fees (assuming publisher aggregation of the type described in the paper).
They also mention that unilateral exit with ZKPs is theoretically possible with bitvm, but nothing concrete.


Disclaimer: this is all from an hour of 'generally reading', not detailed review.

nostr:nevent1qqsqf2sl802c07ztncafvancc6mnvnsp7tsaw7aesn7ju8g8fvwce6qpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygyj99zh08unl59nwk03z4lrm8azpulaynzt3u4u75sv4nmyntmhd5psgqqqqqqsjd8s67 

 Interestingly, something I've just worked on could help with that: issuance based on a utxo snapshot could be made private with https://reyify.com/blog/preserving-proof-of-taproot-assets

... but it could also be simpler, without privacy. Don't see the need to burn, a la spacechains, if you just use a one time snapshot. 

 Sorry that last part about snapshots was dumb; not that it isn't a valid idea, but in no way is it some kind of peg, because it's new issuance, even if controlled. The two way peg concept is the most interesting, and it seems really unclear/difficult with bitvm (given fraud proos onchain a la arbitrum) (not that i know any easy way!).