Will LN liquidity advertisements and dual funding allow for third-party purchased liquidity ("sidecar channels")?

Question

Third-party purchased liquidity ("sidecar channels") are a feature of Lightning Pool where Alice pays Bob to fund a new channel to Carol. Although this seems like an indirection (Alice could just use her funds to open a channel to Carol directly) purchasing liquidity through a third party eliminates Alice's need to hold excess capital or to run a well-connected node---she instead pays Bob for both the temporary trustless use of his capital and the quality of his node's connections, allowing Carol to quickly and reliably begin receiving LN payments through Bob's node.

Liquidity advertisements based on dual funded channels are a decentralized and fully open source alternative to the centralized Lightning Pool marketplace (which has an open protocol but uses a proprietary server). Although both protocols would allow Carol to buy her own liquidity from Bob, only Lightning Pool advertises the ability for third-party Alice to pay Bob for the liquidity he offers Carol.

Is third-party purchased liquidity also possible using liquidity advertisements and dual funded channels?

It at least seems theoretically possible to me. The dual funding would include an input from Alice paying Bob for his liquidity lease but the actual multisig control over the channel funds would be between Bob and Carol. However, it's not clear to me how far this theory is from the reality of what it would take to actually specify and implement that behavior.

Answer 1

Is third-party purchased liquidity also possible using liquidity advertisements and dual funded channels?

It is not currently supported, but Lisa Neigut (niftynei), the primary developer of both dual funded channels and liquidity advertisements, seems to believe it's possible. Two approaches were suggested:

Onchain PSBT workflow

1. Bob publishes a liquidity advertisement (currently supported)

2. Alice notifies Bob that she wants to fund a channel for Carol. This is not currently supported by the protocol and would need to be arranged out of band.

3. Carol requests a channel with liquidity from Bob (currently supported)

4. Instead of asking Carol to fund the channel open and pay for the liquidity (currently supported), Bob asks Alice (not currently supported)

5. Alice sends a PSBT with funding to Bob, Bob returns his half of the PSBT, they both sign and broadcast the funding transaction (like the current protocol but with Alice substituting for Carol).

6. After the funding transactions receives enough confirmations, the channel is fully opened to Carol (currently supported)

Analysis: the security of the above is equivalent to the long-term security of Lightning Labs Pool---onchain protection against double spending. Users who trust Pool not to double spend can opt-in to a short-term weaker security model that allows them to begin spending sooner; that weaker security model and its speed can't be duplicated for liquidity advertisements without additional work.

Offchain workflow

1. Bob publishes a liquidity advertisement (currently supported)

2. Carol requests an offchain invoice for some liquidity from Bob; Bob sends the invoice (sending invoices is currently supported but you'd need a plugin or other software to actually generate these invoices and perform the correct actions when they were paid)

3. Carol forwards the invoice to Alice, who pays it and sends Carol the proof of payment (giving invoice details to another node and them paying it is currently possible; transferring a proof of payment is also currently possible; again, you'd need software, or manual human intervention, to actually do all of that)

4. Carol includes the proof of payment in a request to Bob to receive a channel with liquidity. (not currently supported)

5. Bob opens the channel. (currently supported)

Analysis: this method requires that Alice trust Bob. It may be possible to reduce some of that trust by using an HTLC, but that isn't perfect and adds complications related to hold invoices if it takes the channel a long time to get adequately confirmed onchain. However, the amount of money Alice pays Bob upfront can be as small as the amount of transaction fee needed to confirm the channel onchain---Alice can wait to pay the actual lease cost until after the channel to Carol is fully open. This also means that leases don't need to have a fixed duration and that Alice may even vary subsequent payments to Bob based on Carol's reports about his performance as a routing node.

---

Based on the above, I think third-party purchased liquidity ("sidecar channels") is clearly possible to implement with LN liquidity advertisements and dual-funded channels, although it is not available now.

Please note, all of the above is my own interpretation of a technical discussion about experimental new technology. It may contain errors, and those would be my fault, not Neigut's or anyone else's.