Bit of hosted channels
Hosted Channels
Another tech which might help with the last mile of lightning on-ramps is hosted channels. These are kinda similar to the already covered zero-conf channels in that they are utilizing as much of the lightning protocol as possible in order to maintain as many benefits as possible. But hosted channels make a much larger leap on the “trust for use-ability” trade-off spectrum.
To show the potential benefits of hosted channels, it might be helpful to first look at the full-custodial service solution.
A custodial service is where a user trusts the service completely with the control of their funds.
If a user wants to receive funds on the Lightning Network:
- The service makes an invoice for on behalf of the user.
- The user can go get it paid by someone.
- If paid, the service will earmark in its internal database the funds for the user.
If a user wants to pay for something on the Lightning Network:
- The service would first check if any of the funds in its (not the user’s) payment channel have been earmarked for the user.
- If funds are available, pay the invoice and subtract from the user’s account in the internal database.
The channel funds are in full control of the service. The service is also very aware of everyone the user is paying and receiving from, the privacy benefits of the Lightning Network no longer apply to the user. But dang if it isn’t easy as hell to on-ramp a user! Hosted channels try to pull a bit of the control back to the user. But which parts?
The hosted channel protocol does away with a funding channel, which means they are not back by the layer one blockchain at all (compared to zero-conf which are only exposed for a small window). This means the capacity of hosted channel is a complete IOU. Now that I think on it, the term “channel” might not be very appropriate for hosted channels, since it kinda acts more like an account…but this exact term is mentioned in the official blip-0017…anyways, diving in:
- A client (user) would like to on-ramp to the Lightning Network and asks a host (service) for a new hosted channel.
- The client and the host agree on a channel capacity, this is totally up to them and they are just trusting each other.
- The client and the host each sign a message to establish the hosted channel
- At this point the normal lightning payment channel protocol takes over.
So what are the benefit? Well a ton of the lighting channel protocol is actually still used. And this effectively inserts the user into the HTLC payment flow. Although the user is trusting the service with their funds, any payment will have to go through them. It is no longer possible for the service to pull a fast one and say a payment didn’t come through when it did or lie about making a payment on behalf of the user. The user also regains a lot of their privacy since they will do the routing calculations, the service no longer knows who the other party is in the payments.
The obvious, massive downside is that the channel capacity is backed by nothing. Technically there is an agreement signed by both parties, but if there is a dispute, they are going to have to find someone to care (normal lightning payment channel disputes are settled by the blockchain).
An uncomfortable financial quirk to hosted channels is that they are effectively credit. A service only holding 1 btc could create 10 hosted channels each with a capacity of 1 btc. This system could function as long as there isn’t a classic run on the ban…I mean service.
Does this tech help the “on-ramp to buy a digital coffee” scenario? While its great that the user has more control and privacy compared to the traditional custodial service, I am not sure I consider the user “on-ramp’d” to btc. The user must still completely trust the service to not walk away with their funds, and on the flip side, the service is still a centralized honeypot. I think we can do better.
Next up, mints.