Idea: Unbacked lightning channels (read more before panicking from the title)

[jooray]

The proposal

The idea is simple – specified protocol to allow two nodes to mutually create an “infinite” channel that is not backed by any UTXO, does not have funding transaction, there are no commitment transactions and closing the channel is simply revoking the permission. The channel just passes hashes around to enable payments.

Use cases

Operators of multiple nodes

The usage is strictly among nodes that belong to the same owner. This owner does not care which node holds the balance. An example could be a channel liquidity provider that provides good LN connectivity using multiple nodes – like LNBIG. Before this proposal, they would need to create a channels among their own nodes, unnecessarily locking coins and accounting among nodes.

Gateways between (side)chains – onboarding users on Liquid, paying on Bitcoin via Liquid to Bitcoin Lightning bridge

The unit of account of both Bitcoin and Liquid is Bitcoin. So theoretically, Lightning can use both networks and route among them. There is already a working implementation of clightning for Liquid.

So image onboarding users with fast and cheap channels and allowing them to pay any Bitcoin Lightning invoice, without any kind of exchange rate risk. What is required to do this? You guessed it – unbacked channels. In order for this to work, you have to bridge Bitcoin’s and Liquid’s lightning networks. But you cannot do that easily with backed channels, because the founding transation is 2-of-2 multisig representing both sides of the channel – and this multisig is on one chain.

If someone would like to create a bridge, they would need to run clightning on Liquid, some lightning daemon (possibly also clightning) on Bitcoin and create a trusted unbacked channel. Then they set routing fees, which account for the fact that this bridge would be changing L-BTC to BTC and vice versa (without exchange rate risk, but there are transaction fees).

Now I might hear people talking about decentralization and how they don’t like Liquid. The nice thing about this solution is – you don’t have to like Liquid. If you open channels on Bitcoin blockchain, you gain liquidity of Liquid Lightning users without being exposed to the risk of Liquid. Your channels are represented by UTXOs you agree with – on a chain that you chose. So if you are a store running BTCPayserver and you would like to get paid via Lightning on Bitcoin chain, just open channels as usual. The coins get magically converted by a bridge from L-BTC to BTC on the way. No additional risk for you.

Yet, you gain access to the payment network of possible users, who chose faster, cheaper and confidential transactions, while giving away a bit of decentralization. And the unit of account is still Bitcoin.

Use multiple daemon implementations

So you like to use Zap wallet on your iPhone with your lnd lightning node. But on the server, you like to use Lightning Charge, which works on top of c-lightning. What do you do? You install both lnd and c-lightning, make sure you have safe backups for both nodes, lock some of your capital to directly connect your lnd and your c-lightning together and open some channels.

With unbacked channels, this is completely unnecessary. You install lnd, open only one unbacked channel to your c-lightning that shows the whole send and receive capacity of your c-lightning node (so your Zap wallet displays correct balances). You open channels on your c-lightning node and make sure you back it up. In case of a problem with lnd, you can safely delete it – there are no funds on it (unless you receive an onchain transaction or open a channel directly to your lnd).

While it would be nice if all major Lightning node implementations had a unified RPC API, I guess at this point in development of lightning, it is better if we let the implementations innovate on their own and standardize only on the protocol level. Creating unbacked channels solves this problem in a unique way – you can run all node implementations independently, while maintaining one set of channels.

Learn more

I wrote a blog about this proposal, with risks and other thoughts. The blog is "unlicensed", do whatever you want with it.

[evd0kim]

That's Hosted Channels basically. They are better because they are already working.

https://github.com/btcontract/hosted-channels-rfc

[jooray]

Thank you. Do you know of documentation about implementation in any existing lightning nodes?

I would like to check how it's implemented and see if it is possible to do all the things I wanted to do.

[evd0kim]

It is currently implemented only in the Eclair node. Before such Hosted channels were supported only in the custom fork of the node maintained by Bitcoin Lightning Wallet developer.

I understand it is nearly impossible to develop the same functionality for various clients. Just a huge amount of work and different stacks. It must be done by node maintaining teams.

[akumaigorodski]

Hi, currently I'm finalizing my work on something which does more or less what you want (and more) here: https://github.com/btcontract/plugin-hosted-channels.

Launching an Eclair node with this plugin will enable private hosted channels which match your Zap-LND case as well as public hosted channels which are inspired by this post: https://www.rene-pickhardt.de/index.html%3Fp=2131.html. These will be visible to other network participants and usable for routing.

There's no RFC for public part, it only exists in plugin code for now, specs are to be added soon.

[greedyradar]

I'm interested in restarting this conversation, because I am not sure hosted channels can expand beyond a bitcoin-denominated system. Consider the following:

There are five people considering opening a channel to one another. Alice has bitcoin and she runs LND over bitcoind. Bob has bitcoin and he runs C-Lightning over bitcoind. Charlie has litecoin and he runs C-Lightning over litecoind. Debbie has liquid bitcoin and she runs C-Lightning over elementsd -network=liquidv1. Earl has share tokens of Coca-Cola he bought on the market and he runs C-Lightning over elementsd -network=NYSE

For Alice to create a channel to Bob is trivial. They use the existing protocol and exchange bitcoin at will.

For Alice to create a channel to Debbie is slightly more complex, since bitcoin and liquid bitcoin are different tokens. However, the rate of exchange between them is fixed, so swapping them 1-for-1 can be built into the logic of the channel as discussed in this thread.

For Bob to create a channel to Charlie is more complicated still, since bitcoin and litecoin are different tokens and they must exchange at a market rate. The same is true for any channels opened with Earl. While they both operate independent sidechains on the Elements platform, they trade tokens which (in the case of Earl) float on a stock market.

How shall these participants establish channels to each other?

ALICE AND DEBBIE

Consider that Alice has 500,000 sats and Debbie has 600,000 l-sats. When this channel is formed, it will have an attribute that ordinary lightning channels do not – the concept of an ‘allocation’. For example, the channel will have an allocation of 500,000 satoshi (expressed as 500,000,000 millisatoshi) and 600,000 liquid satoshi (expressed as 600,000,000 milliliquidsatoshi). You can imagine an ordinary lightning channel between Alice and Bob as having only one allocation – millisatoshi.

Figure 1. Alice/Debbie Channel Balance

Alice<500,000,000-----------------------millisatoshi----------------------------------------------0>Debbie Alice<0------------------------------------milliliquidsatoshi----------------------------------600,000,000>Debbie

However, it is not enough to fund the channel, each participant must be able to encode and decode invoices written in the others’ token and must present an on-chain settlement address of their counterpart's chain to collect the others’ token in the event of channel closure. This ability is likely to be incorporated in the form of a plug-in for Debbie’s C-Lightning instance (or Eclair instances), but must be written into the master of future versions of the other implementations.

Afterwards, each can forward payments on their respective chains, and act as a bridge between the two for their extended network, without those participants being required to interface with the foreign token in any way, as OP stated.

BOB AND CHARLIE

Let’s say that Bob has 300,000 satoshi and Frances has 3,000,000 litoshi. When this channel is formed, it has the attribute of allocation as above, but it also has a second attribute, called a ‘tranche’. A tranche in this case is somewhat like the lowest common denominator in an exchange between the two tokens. To simplify the example, image the exchange rate is a fixed amount of 1:250, so a tranche of satoshi is 1 and a tranche of litoshi is 250. Again, we’ll express this as millisatoshi and millilitoshi.

Figure 2. Bob/Charlie Channel Balance

Bob<300,000,000-------------------------millisatoshi---------------------------------------------0>Charlie Bob<0--------------------------------------millilitoshi-------------------------------3,000,000,000>Charlie

In the above, every time 1000 millisatoshi move from Bob’s side of the channel to Charlie’s, 250,000 millilitoshi move from Charlie to Bob. As you no doubt have guessed, the problem is that the exchange rate between bitcoin and litecoin is not fixed, nor is the value of Earl’s Coca-Cola share tokens. Therefore we must have two classes of tranche – a static tranche and a dynamic tranche. In a way, you can image Alice and Debbie utilizing a static tranche of 1-to-1 in their channel, but the value need not be nominally equivalent.

DYNAMIC TRANCHES

When Bob and Charlie negotiate their channel open, they must set an allocation for their respective tokens, and they must agree on an oracle to establish their tranche ratio and the frequency of its update. Here, I see two scenarios: one in which the subordinate chain (the non-bitcoin denominated chain) submits its own valuations, and one in which a third-party or collection of third-parties submit valuations. Each scenario presents its own risk profile, and it is likely both will exist concurrently. Organizations like the NYSE will have a tremendous advantage here, given the trust typically placed in their model, as most participants will accept that they have some authority on the price of a share of Coca-Cola. However, new services like Bisq may provide a trustless source of price discovery should the market in question have sufficient size and usage. So we now have a concept of ‘trusted dynamic tranche’ and ‘trustless dynamic tranche’ which must be set as parameters at channel open.

How can that be done? Is there a better overall approach?