-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RGB assets routing #12
Comments
Follow up question... Usually, spectrum DEX is the way to do routing across the incumbent lightning network. However, what if there is a local micro network where there is a possible route that stays inside the same asset type? So, |
@MaxHillebrand You mean Spectrum here? |
You don't need anything special to use RGB this way, you just need to know the channels are all made of the same RGB tokens, afaik I am in side discussion w some people about a different solution for coordination stuff like this though. I think maybe we can do a lot in a simpler way. |
For routing to properly work I believe it is needed to have asset specific sub-networks of LN channels, the DEX should be used only when a direct path to the destination does not exist and to connect isolated users to the sub-network. If everyone just use the DEX over the incumbent LN then you are basically just moving bitcoins around, not assets. |
Just going back to read dev calls issues, I don't remember having heard about this during calls, my apologies if it was already discussed.
|
The design for channel routing/typing/advertising is still a WIP, I think. @dr-orlovsky could answer better, but I think we are still open to suggestions and assistance! Generally, abstractions on BTC do require "taint"-like behaviors, but there are definitely ways to limit silo info to need-to-know parties, P2P. The easy/non-private way is probably something like RGB keeping and sharing a single index, I think Liquid does something like this. Even so, typing a channel isn't a huge privacy leak. Plenty to discuss! |
Will a RGB channel be able to be used to route bitcoin transactions as well?
At a first sight I'd say it's enough to have a local view on RGB-token subnets to be able to find a path if the algorithm is appropriate, Might make sense to spend some time on this. Hope this makes sense, I'm digging a bit into LN routing algorithms these days; I'll post here if I have valuable insights. |
Technically RGB channels could be used to route bitcoin transactions, however, from my understanding, the price exposure to RGB assets may make this impractical. For example, say Alice is routing a payment to Bob. A(BTC)->B(RGB USDT)->C(BTC)->D In this scenario, Bob has increased his exposure to BTC while decreasing his exposure to USDT. On the other hand, Carol has increased her exposure to USDT while decreasing her exposure to BTC. In other words, an atomic swap has occurred. In order to maintain their prior exposure to BTC/USDT, Bob would need to sell USDT for BTC, and Carol USDT for BTC. This may be easy if they both have channels with a BTC/USDT DEX. However, both these parties would need to indicate that they are okay with atomic swaps occurring within their existing channels. Another downside is this scenario runs into the call option problem. If Alice wishes to route BTC through RGB channels, then she may need to pay a call premium or risk having Bob or Carol try to time the market while atomic swapping between BTC / USDT. Realistically IMO it will only make sense for market makers or liquidity providers to have their RGB channels route BTC payments, although this still needs to be discussed. Am I missing anything @dr-orlovsky? |
By "routing btc payments" I meant forwarding a regular LN payment as if the channel was not even rgb. So, if it's even possible, no asset exposure would be affected, since tokens would be left untouched and only btc moved. To perform atomic swaps you still needs rgb channels to advertised somehow. I agree there might be a usecase for this someday, but those channels will end up in the first case I listed anyways. |
How does routing work with assets issued on top of RGB?
Is there a certain amount of sats attached to each asset sent across the network?
Question raised by @matthewjablack in RGB Q&A group
The text was updated successfully, but these errors were encountered: