Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Hosted channels

An idea has been suggested shortly after publishing turbo channels post, the gist was: if we can have a channel where a funding transaction is temporarily not on a blockchain, perhaps we could also have a channel without a funding at all? It was dismissed at the time but currently my opinion is that this idea has its merit.

Why bring this up at all

The way I see it there is a certain kind of specialization happening in Lightning, two distinct evolution paths are tried:

  • The first path, which I'm very optimistic of, is a network of relatively low number of LN nodes running on servers and belonging to various organizations which settle their debts through a relatively low number of fat public channels. This is a no-brainer, very sane approach that will definitely happen at scale once LN stops feeling dangerously new.

  • The second path is a "massive adoption" idea which is that everyone can have a small lightning node in their pocket and initial plan for getting there was private channels. The plan is still on and many firmly believe they can pull it off, but having some expirience in an area my opinion is it's going to be an extremely hard task to accomplish as obstacles are far too serious.

What exactly is wrong with private channels at scale

The belief is more or less that various forms of LSPs will save the day while a major remaining issue is UX which can be improved and then adoption will come, but far more serious issues exist beyond UX, namely it's that economy of a whole thing does not add up:

  • First, a liquidity provider needs to pay some on-chain fee for every private channel it opens and lose money on each new client. This can be mitigated by making user pay that fee as ACINQ wants to do with their Phoenix project, but that makes user pay for entry right from the get go which is generally not expected from payment systems that Lightning competes with.
    This is probably fine though while on-chain fees remain low but they are projected to rise as time goes by and especially in case if Phoenix and similar approaches become successful an entry fee would turn out to be a natural growth limiting factor.

  • Second, a liquidity provider needs to allocate a sizeable amount of BTC for most of these channels to ensure decent capacity and then a rational provider would expect each channel to be used a lot, all the time or be closed soon because this is an investment just like any other: funds contained in a channel could be used for more profitable purposes and having them sitting in a hot wallet while rarely doing anything is clearly undesired.
    Plus, once VC money runs out a provider would very likely have to constantly close existing channels to obtain funds for new ones. What's worse is it's not even clear how much usage is enough to stay open since unless provider offers some kind of additional services the only source of income would be routing fees which tend towards zero.

    Existing liquidity providers know all this so they warn users beforehand which sadly provides for a terrible UX (which can not be fixed on UX level).


    Thor from Bitrefill

  • Third, once provider gets to this point, closing rarely used channels is not exactly a clean process: remote peer would most certainly be offline which means force-close with even more on-chain fees and long wait times. Empirically we already have a first example of large scale provider trying to earn money this way and so far results look bad.

Existing alternative VS hosted channels

Another road to mass adoption would be custodial wallets and despite an obvious drawback of funds not being under full user control this approach to scalability does feel very straightforward and workable.

That said, a major issue here is that current generation of LN custodians basically destroys everything which makes Lightning an interesting offer in a first place by lowering privacy and rising trust assumptions to never before seen lengths. They are so ridiculously bad at this I'd argure they are worse than on-chain custodial wallets because with those at least a chain history is in place while with current LN custody nothing is provable or verifiable. This itself seems to be another limiting factor as not that many people would want to use such systems once they find out that giving up on entirety of their financial activity is a must.

However, current state of affaris can be improved and this is what hosted channels are about: it's a protocol intended to replace current custodians with a novel approach which retains unique Lightning privacy properties and provides remote accountability for those funds which are no longer under full local control.

Technically, a new type of channel is introduced which has no on-chain funding but otherwise works according to LN rules, it is designed to coexist with normal channels and be seamlessly used for payments including advanced payment techniques like AIR or AMP.

How a hosted channel compares against a full blown custodial wallet

Custodial wallet Hosted channel
Funds are hosted on a remote machine Yes Yes
On-chain funding is required No No
Immediately usable for LN payments (sending and receiving) Yes Yes
Easy recovery (user is only assumed to have a mnemonic phrase) Yes Yes
Multiple devices are supported Yes Yes
Cryptographic proof of user balance Bad No, host can remove an entire user balance and pretend it was never there Good Yes, each balance update is cross-signed by user and host, latest cross-signed state represents current user balance and is stored locally
Outgoing payment destination is known by host Bad Yes, a complete payment route is constructed on host server Good No, payment route is constructed locally in user wallet, host only gets an encrypted onion, this is similar to normal channels
Host can censor payments to certain destination Bad Yes, because payment destination is always known by host Good No, as a consequence of payment route being constructed in user wallet host does not know a destination so can not selectively censor
Outgoing payment description is known by host Bad Yes, an invoice is generated on host server so entire payment metadata is known to them Good No, invoice is generated locally in user wallet, host knows no payment details
Preimage for incoming payment is known by host Bad Yes, as a consequence of invoice being generated on host server. This allows host to fulfill incoming payment without updating user internal balance Good No, preimage is generated in user wallet and is only revealed after host signs an obligation to update user balance on obtaining a preimage
Offline receiving is possible Good Yes, as a consequence of invoice being generated on host server Bad No, as a consequence of invoice being generated in user wallet
An entire payment history in known by host Bad Yes, full payment history is stored on host server Good No, payment history is only stored in user wallet, plus user may have normal channels besides a hosted one so host can not fully know even a basic info like sent/received amounts
Host knows with certainty that user is the sender or final receiver of payment Bad Yes since user has a thin wallet which in principle can not do routing Good No because technically user has a real LN node and payment could have been a routed one, so plausible deniability is there
User identity is known by host Some custodians require this, others don't No such requirement on a hosted protocol level
Payment fees Depends on custodian, most popular ones take 0.3% + routing fees (route is picked by custodian, user has no say in this) Good Just routing fees with route selected by user wallet, similar to normal channels
Technical implementation Bad Custom for each wallet, user is bound to use a certain wallet if they trust a certain custodian Good A common protocol, user is free to choose between many wallets to use the same host, as well as between many hosts to be used through the same wallet
Every user has their own nodeId Bad No, all users share the same nodeId so for instance this tweet is correct Good Yes, since user wallet is still an LN node so various signing schemes still work perfectly fine
User education Bad A dominant approach is that users should not be educated and just use what is given Good "Easy to start and possible to master": as simple as custodial wallet for users not willing to learn but exposes channel mechanics and provides direct ways to opt out for those who do

How a hosted channel looks like

First wallet launch, first LN payments

First wallet launch

Expirience here is similar to custodial wallets: LN is usable right away (+ testnet users get a 25000 SAT bonus).

Hosted and normal channel are seamlessly used for AIR (and soon multipart)


There are two channels in a wallet where one is hosted and another one is normal. None of them has enough balance to fulfill 170k SAT invoice on its own so wallet makes a first payment which refills one local channel from another, then a final 170k payment from refilled channel.

Opting out for advanced users

Opting out

One can receive funds into hosted channel, then transfer from hosted to normal one, then remove a hosted channel.

Use cases

Here's a bunch of hopefully plausible scenarios:

  • Alice wants to know nothing about Bitcoin, let alone Lightning but a customer prefers to pay via LN for her freelance work. She installs a wallet with a hosted channel support, immediately issues an invoice and receives an up-front payment. Everything works exactly as Alice would expect given her expirience with other payment systems so she keeps using this one.

  • Bob usually does on-chain payments only but right now he needs to place a bet ASAP at a site which accepts Bitcoin and Lightning. Speed is key here so Bob purchases a voucher at a local shop, then scans a QR and gets a hosted channel with inital balance set to purchased amount, then immediately proceeds to placing a bet and removes a hosted channel once done.

  • Dave is an expirienced trader who has a lot of funds in channels and uses them for arbitrage whenever an opportunity comes by, he strongly prefers to keep funds in local normal channels to reduce his risks but sometimes incoming amounts exceed total capacity he has at the moment so he uses a hosted channel as a temporary capacity buffer which then gets drained into extended normal channels.

  • Eve shares a single full LN node with her family but parents want to limit an amount of funds she can spend and also she does not want her payment history to be stored on that node for other family members to see, so she gets a hosted channel of certain capacity to her own family node which gets refilled as she runs low on funds.

  • Ivan believes in "not your keys, not your coins" so he removes a hosted channel at first sight and instead proceeds with normal ones because he's totally fine with UX tradeoffs.

Resources and working demo

Protocol spec

Eclair implementation

BLW implementation

Working testnet APK


This comment has been minimized.

Copy link

@waldo2590 waldo2590 commented Sep 14, 2020


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.