pull down to refresh
380 sats \ 14 replies \ @dr_orlovsky OP 10 Jul \ parent \ on: RGB consensus layer released to production rgb
The main reason of its not being used is the fact that it was not released for production (until today). Consensus in client-side validated systems (RGB belongs to them) is kind of ossified from the day one when you start using in production; it is much harder to change that than blockchain consensus. Thus, it took many years to build a system which has everything needed, including zk-STARK readiness.
I am quite sure we will see a boost in RGB adoption over the next months after the release.
Wow, this is pretty exciting! I'll be quite interested to see what kind of consumer applications take it up.
reply
My money is on more shitcoins, but I hope to be mistaken
reply
Not just shitcoins. Also:
- better liquidity on lightning
- much better privacy (broken tx graph)
- souvereign legal system
- sovereign bearer audit logs (timestamps++)
- better bitcoin programmability (much better)
With Prime (client-side validation layer 1):
- 1 sec settlement time
- no blockchain
- tens of millions tx per second with no inbound liquidity problems like in lightning
- constant size data with zk-STARKs client-side peer-to-peer proofs
And yes, there is bitcoin trustless bridging to RGB and Prime - with Radiant and/or BitVM (whatever happens first).
reply
cool, thanks! I've been trying to follow this some time ago. will look more closely now.
reply
reply
The problem solved by Alice sending BTC to Dan via USDT on the route is utilization of additional liquidity which will be present in LN only with RGB.
PPM fee still will be lower than onchain tx fee if liquidity is just not there and Alice can't pay Dan
Free option problem is always there in any atomic swap protocols; the way to mitigate it is just to set a proper CTV timeout and experience more failures.
reply
There is no free option in atomic swaps on sideswap.io
on LN, even 1 block CTV is enough to be exploited
Right now the only liquidity present in Lightning network is BTC liquidity.
Yet stable coins (like USDT) has much more liquidity (most of BTC is on long-term holding and thus non-liquid, and would never touch LN). Once they come into lightning channels payments can be routed through channels with no BTC liquidity (but with USDT etc), converting on-the-fly; so BTC payment may pass through such channels in a transparent way.
reply
This on-the-fly converting idea is nonsense. Who would want to cross two bid/ask spreads to receive x% less? And who would dare to be an exit node and be picked off by free option? I will be the first to game them. Maybe native USDT channels will work, but that will require a whole alternative LN, with rebalancing pain etc. USDT on Liquid does the job great right now, with cheap confidential payments and atomic swaps to/from BTC.
Consensus in client-side validated systems (RGB belongs to them) is kind of ossified from the day one when you start using in production
Why is that? Is it a technical reason?
reply
Yes, there is a pure technical reason.
In client-side validation there is no P2P network like in blockchain; you validate only part of the global history and state directly related and interested to you. Thus, if somebody in that history uses something which was valid for him, and you have a newer software in which this have become invalid (like in soft-fork in bitcoin blockchain), you will decline these data, meaning that that part of the history will be lost forever after such a change.
Also, in bitcoin blockchain you can target update events using blockchain as a Time Machine; in client-side validation there is no full order of events and you can't say that "After time point X a thing becomes valid/invalid", so no means of coordinating updates.
reply