New blog post: https://petertodd.org/2025/fake-channels-and-rgb-lightning
tl;dr: the fact that you can route over fake channels on lightning, means implementing Lightning on top of client-side-validated tokens like RGB is much easier than you'd expect.
Probably not a new idea. But someone's gotta write it down...
Yeah, I've seen this twice. Already implemented in hosted channels and proposed as a way to allow people running multiple LN implementations to forward without having a channel.
To be clear, the (possible) innovation isn't fake channels. The innovation is taking advantage of them to implement Lightning on top of client side validated tokens.
Yeah, that might be interesting and I wouldn't be surprised if there are more interesting uses of fake channels. The issue is LN doesn't support them yet because, as you mentioned, it needs DoS protection.
Getting an alternative DoS protection would be great for privacy too.
FYI: virtual channels are implemented since 2022 in LDK for [load balancing](https://bitcoinops.org/en/newsletters/2022/02/23/#ldk-1199) and [JIT channels](https://bitcoinops.org/en/newsletters/2022/12/14/#ldk-1835).
Yes, there's a lot of variations of the idea for clients with private channels. But in my article I'm specifically talking about public channels. That's what makes them interesting for lightning over client-side-validated tokens: arbitrary nodes can route payments over them without having to validate that the channels are real. That drastically reduces the total amount of data you need to route.
Is this a similar concept to phantom channels that nostr:npub19tcpurtt6xulhw0r6sc404j9jraj0h8me2lzs7z2tqewz7l0hpas59nlea uses for Ghost Addresses?
Yes and no. The mechanism I'm proposing to take advantage of it similar. The the reason why I think it's useful has nothing to do with Ghost Addresses.
I'm so glad you asked this! There might be even more interesting applications to explore from ghost addresses in a cross asset ecosystem.
I don't know anything about Asset Universes. I thought TA was basically refusing the existing LN by only resolving assets at the endpoints. E.g., A to B is foocoin, B to C is BTC, C to D is foocoin. It sounds like you're proposing A to B is trustless foocoin, B to C is two parties claiming to xfer foocoin but really looking up the foocoin exchange rate and swapping an equivalent amount of BTC instead, and C to D is trustless foocoin. That seems fine but the TA method seems to have a larger network and so stronger network effects, especially for rarely used assets.
Yeah, I think you don't understand my article at all.
It has nothing to do with exchange rate swaps; what my article proposes is completely orthogonal to that trick.
My point is that the sender doesn't need to validate whether or not any intermediary channel along the route is real at all, and that makes client side validated tokens much more feasible to use for lightning than people expect.
Correct, I'm baffled by your article. What's the point? I feel like I'm missing some context, which is why I mentioned not knowing anything about Asset Universes.
The fact that other people _can_ have virtual channels only seems useful if they _want_ to have virtual channels. So why would they want to advertise support for relaying payments denominated in a CSV token that they don't own (because if they did own it, they wouldn't need a virtual channel)?
The point isn't that people will advertise channels based on CSV tokens that they don't actually own. The point is that clients don't have to care whether or not the channels are real: public routing works fine whether or not the channels are real, so validation is unnecessary.
Thus, the amount of bandwidth you need to successfully route, say, a USD token implemented on a CSV scheme like RGB is much less than you'd expect, as you don't need to fully validate every channel. (Remember that validating a single CSV token txout might require megabytes of proof data)
I see. Maybe another way of thinking about that is that trampoline routing is also an option, as it is on BTC-LN. E.g., Alice and Zed don't care about the specific hops between them: they only care that the money arrives, that the total forwarding fee is less than x, and (for some users) that no third party can easily learn the identity of both the spender and the receiver.
Trampoline routing is not a comparable option as it has much worst privacy.
The remarkable thing here is that you can do fully self sovereign routing, with full privacy , over a lightning routing network without validating any channels other than your own.
The only requirement is having an anti-DoS mechanism for channel advertisements. There's lots of obvious ways to do that, such as generic proof-of-sacrifice.
There was also talk of cashu-token backed lightning channels. I don't think it matters to the ln network how the channels are secured, it only matters to the first and last node in the ln route whether they get paid.
