On-the-fly channel liquidity (LSP-initiated)

on-the-fly-liquidity.md

On-the-fly channel liquidity

Table of Contents

• Abstract
• Specification
  • Feature bits
  • The propose_funding_htlc message
  • The fail_funding_htlc message
  • The accept_funding_htlcs message
  • Extensions for the open_channel2 and splice_init messages
  • Extensions for the update_add_htlc message
  • Dealing with malicious recipients
• Examples
  • Channel creation
  • Channel creation with multiple HTLCs
  • Splice with multiple HTLCs
  • HTLC rejected after funding
  • Disconnect and reconnect

Abstract

When a routing node is asked to relay payments but the destination is lacking inbound liquidity, the routing node usually simply fails that payment. That is a missed opportunity to earn fees, and a poor user experience. We propose a protocol to add more liquidity on-the-fly to be able to route those payments and earn additional fees for the liquidity provided.

This is particularly useful when combined with zero-conf (to avoid locking up HTLCs while the additional liquidity is waiting for confirmations) for mobile wallet users. But this isn't limited to those use-cases, and can make sense between routing nodes as well.

Specification

Feature bits

Bits	Name	Description	Context	Dependencies
260/261	on_the_fly_funding	On-the-fly channel funding	IN

Nodes may activate this feature bit when they want to add more liquidity to lightning channels when incoming payments require it.

The propose_funding_htlc message

1. type: 33000 (propose_funding_htlc)

2. data:

   • [chain_hash:chain_hash]
   • [32*byte:proposed_htlc_id]
   • [u64:amount_msat]
   • [sha256:payment_hash]
   • [u32:cltv_expiry]
   • [1366*byte:onion_routing_packet]

3. tlv_stream: propose_funding_htlc_tlvs

4. types:

   1. type: 0 (funding_rates)
   2. data:
      • [u32:fee_base_sat]
      • [u16:fee_proportional_basis]

Requirements

The sending node:

• If it wants to forward an HTLC, but doesn't have a channel with enough funds for it, and the receiving node supports on_the_fly_funding:
  • MAY send propose_funding_htlc if it is able to fund a channel for the corresponding amount.
  • MUST generate a unique proposed_htlc_id.
  • If this is a forwarded payment from a downstream channel:
    • MAY deterministically derive proposed_htlc_id from the downstream channel_id and htlc_id.
  • MUST include amount_msat, payment_hash, cltv_expiry and onion_routing_packet as if it were sending update_add_htlc.
  • MUST include funding_rates for the funding fees it will collect after funding the channel.
  • SHOULD include on-chain fees for the funding transaction in fee_base_sat.
  • If a disconnection happens before receiving fail_funding_htlc or accept_funding_htlcs:
    • MUST forget this propose_funding_htlc.
• Otherwise:
  • MUST NOT send propose_funding_htlc.

The receiving node:

• If it finds the funding_rates acceptable:
  • MUST decrypt onion_routing_packet and handle it as if it came from an update_add_htlc message.
  • If it would have failed that update_add_htlc:
    • MUST send fail_funding_htlc.
  • If it would have fulfilled that update_add_htlc:
    • MUST send accept_funding_htlcs.
  • If a disconnection happens before the corresponding channel funding starts:
    • MUST forget this propose_funding_htlc.
• Otherwise:
  • MUST send fail_funding_htlc.

Rationale

When a node is asked to relay a payment on a channel where there isn't enough liquidity, it may provide on-the-fly liquidity on that channel to be able to relay that payment and collect the corresponding routing fees. Recipients are then able to reliably receive payments without actively managing their inbound liquidity.

propose_funding_htlc is very similar to update_add_htlc and must be handled similarly: the recipient must decrypt the onion and aggregate payments (when they are using multiple parts) before deciding whether to accept or reject a funding proposal.

The sender gives its current funding_rates to the recipient, which covers the on-chain fees for the corresponding funding transaction and the additional liquidity that is provided.

In most cases, the sender is relaying HTLCs from downstream channels. It must settle those HTLCs to avoid locking liquidity in the network for too long. It thus provides an explicit, absolute expiry to the recipient before which they must decide whether to accept or reject the funding proposal.

If nodes are disconnected, they should forget all pending funding proposals. This removes the need for explicit state tracking and reconnection handling. The funding proposal can be restarted from scratch on reconnection.

The fail_funding_htlc message

1. type: 33001 (fail_funding_htlc)
2. data:
   • [32*byte:proposed_htlc_id]
   • [u16:len]
   • [len*byte:reason]

Requirements

The receiving node:

• MUST forget the corresponding propose_funding_htlc.
• SHOULD fail any matching downstream HTLC, if any.

The accept_funding_htlcs message

1. type: 33002 (accept_funding_htlcs)

2. data:

   • [chain_hash:chain_hash]
   • [u64:max_funding_fee_msat]

3. tlv_stream: accept_funding_htlcs_tlvs

4. types:

   1. type: 0 (funding_rates)
   2. data:
      • [u32:fee_base_sat]
      • [u16:fee_proportional_basis]
   3. type: 1 (proposed_htlcs)
   4. data:
      • [...*32*byte:payment_hashes]

Requirements

The sending node:

• MUST set funding_rates to the last received funding_rates from the remote node's propose_funding_htlc.
• MUST set max_funding_fee_msat to the maximum fee it is prepared to pay for additional inbound liquidity.
• MUST include that payment_hash of all pending propose_funding_htlc in proposed_htlcs.

The receiving node:

• If max_funding_fee_msat is too low:
  • SHOULD send a warning and disconnect.
• If funding_rates don't match the latest rates:
  • SHOULD send a warning and disconnect.
• Otherwise:
  • MUST initiate the funding flow to add more liquidity towards the sending nodes, using the provided funding_rates.

Rationale

The recipient of a payment sends accept_funding_htlcs to let the other node know that they can proceed with adding more liquidity to forward HTLCs matching the provided payment_hashes. They echo the last received funding_rates to acknowledge that they accept those rates and will allow the corresponding fees to be deduced from future HTLCs forwarded on that channel.

There is a proportional fee based on the amount that the other node will fund. The sender can put a threshold on that amount by setting max_funding_fee_msat which implicitly tells the other node to avoid adding too much liquidity, or to add it without additional fees.

When nodes cannot agree on funding parameters, they disconnect, which resets the state.

Extensions for the open_channel2 and splice_init messages

1. tlv_stream: open_channel2_tlvs

2. types:

   1. type: 65537 (funding_fee)
   2. data:
      • [u64:funding_fee_msat]

3. tlv_stream: splice_init_tlvs

4. types:

   1. type: 65537 (funding_fee)
   2. data:
      • [u64:funding_fee_msat]

Requirements

The sending node:

• If it is responding to accept_funding_htlcs:
  • MUST set funding_fee to the fee it will collect from future HTLCs for the liquidity it is providing to the receiving node.
  • MAY include the on-chain fee it will pay for the funding transaction.
  • MUST NOT exceed the max_funding_fee_msat from accept_funding_htlcs.

The receiving node:

• If funding_fee is not acceptable:
  • MUST send error to reject the funding attempt.
• Once the corresponding funding transaction has been confirmed:
  • MUST allow future HTLCs to subtract funding_fee_msat from their amount.

Rationale

When adding on-the-fly channel liquidity, the receiving node may not have any way of paying fees upfront. Those fees are instead collected from the future HTLCs forwarded on that channel.

Extensions for the update_add_htlc message

1. tlv_stream: update_add_htlc_tlvs
2. types:
   1. type: 65537 (funding_fee)
   2. data:
      • [u64:funding_fee_msat]

Requirements

The sending node:

• If it recently funded a channel in response to accept_funding_htlcs, and hasn't fully collected the corresponding fees:
  • SHOULD set funding_fee to a value smaller than or equal to the remaining fees it should collect.
  • MUST deduce funding_fee from the amount_msat it would have otherwise sent.
  • MAY set funding_fee to a fraction of the fees it needs to collect.

The receiving node:

• If funding_fee is set:
  • If funding_fee is greater than the remaining fees it owes the sending node for the channel liquidity that was provided:
    • SHOULD send a warning.
    • MUST fail the HTLC.
  • MUST handle the HTLC as if its amount was amount_msat + funding_fee.

Rationale

Funding nodes get paid for the liquidity they provide by subtracting their fees from HTLCs. It is possible to spread out the fees across multiple HTLCs (e.g. in case MPP was used). The receiving node must keep track of its remaining debt and accept funding_fee accordingly.

Dealing with malicious recipients

The node that is funding additional liquidity is taking a risk, because it is funding upfront and getting paid the corresponding fees later. A malicious recipient would send accept_funding_htlcs, wait for the additional inbound liquidity, and then fail HTLCs that set a funding_fee.

When that happens, the funding node should keep subtracting the funding_fee from the next HTLCs it forwards. The receiving node must eventually accept them, otherwise it won't receive anything, which makes the attack worthless.

If the receiving node keeps failing HTLCs, the funding node should eventually close the channel and blacklist the receiving node. The funding node may also double-spend the funding transaction, if it wasn't confirmed, which avoids the additional closing on-chain fee.

Examples

The following examples can also act as test vectors.

Channel creation

 Alice                         Bob                             Carol
   |       update_add_htlc      |                                |
   |  amount = 50_100_000 msat  |                                |
   |--------------------------->|                                |
   |                            |      propose_funding_htlc      |
   |                            |    amount = 50_000_000 msat    |
   |                            |------------------------------->|
   |                            |      accept_funding_htlcs      |
   |                            |<-------------------------------|
   |                            |          open_channel2         |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |------------------------------->|
   |                            |         accept_channel2        |
   |                            |<-------------------------------|
   |                            |         channel_ready          |
   |                            |------------------------------->|
   |                            |         channel_ready          |
   |                            |<-------------------------------|
   |                            |         update_add_htlc        |
   |                            |    amount = 49_000_000 msat    |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |------------------------------->|
   |                            |       update_fulfill_htlc      |
   |                            |<-------------------------------|
   |    update_fulfill_htlc     |                                |
   |<---------------------------|                                |

Channel creation with multiple HTLCs

 Alice                         Bob                             Carol
   |       update_add_htlc      |                                |
   |  amount = 30_100_000 msat  |                                |
   |--------------------------->|                                |
   |                            |      propose_funding_htlc      |
   |                            |    amount = 30_000_000 msat    |
   |                            |------------------------------->|
   |       update_add_htlc      |                                |
   |  amount = 20_050_000 msat  |                                |
   |--------------------------->|                                |
   |                            |      propose_funding_htlc      |
   |                            |    amount = 20_000_000 msat    |
   |                            |------------------------------->|
   |                            |      accept_funding_htlcs      |
   |                            |<-------------------------------|
   |                            |          open_channel2         |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |------------------------------->|
   |                            |         accept_channel2        |
   |                            |<-------------------------------|
   |                            |         channel_ready          |
   |                            |------------------------------->|
   |                            |         channel_ready          |
   |                            |<-------------------------------|
   |                            |         update_add_htlc        |
   |                            |    amount = 49_000_000 msat    |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |------------------------------->|
   |                            |       update_fulfill_htlc      |
   |                            |<-------------------------------|
   |    update_fulfill_htlc     |                                |
   |<---------------------------|                                |
   |    update_fulfill_htlc     |                                |
   |<---------------------------|                                |

Splice with multiple HTLCs

 Alice                         Bob                             Carol
   |       update_add_htlc      |                                |
   |  amount = 30_100_000 msat  |                                |
   |--------------------------->|                                |
   |                            |      propose_funding_htlc      |
   |                            |      proposed_htlc_id = 1      |
   |                            |    amount = 30_000_000 msat    |
   |                            |------------------------------->|
   |       update_add_htlc      |                                |
   |  amount = 10_500_000 msat  |                                |
   |--------------------------->|                                |
   |                            |      propose_funding_htlc      |
   |                            |      proposed_htlc_id = 2      |
   |                            |    amount = 10_000_000 msat    |
   |                            |------------------------------->|
   |                            |        fail_funding_htlc       |
   |                            |      proposed_htlc_id = 2      |
   |                            |<-------------------------------|
   |      update_fail_htlc      |                                |
   |<---------------------------|                                |
   |       update_add_htlc      |                                |
   |  amount = 20_050_000 msat  |                                |
   |--------------------------->|                                |
   |                            |      propose_funding_htlc      |
   |                            |      proposed_htlc_id = 3      |
   |                            |    amount = 20_000_000 msat    |
   |                            |------------------------------->|
   |                            |      accept_funding_htlcs      |
   |                            |<-------------------------------|
   |                            |          splice_init           |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |------------------------------->|
   |                            |          splice_ack            |
   |                            |<-------------------------------|
   |                            |         channel_ready          |
   |                            |------------------------------->|
   |                            |         channel_ready          |
   |                            |<-------------------------------|
   |                            |         update_add_htlc        |
   |                            |    amount = 49_000_000 msat    |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |------------------------------->|
   |                            |       update_fulfill_htlc      |
   |                            |<-------------------------------|
   |    update_fulfill_htlc     |                                |
   |<---------------------------|                                |
   |    update_fulfill_htlc     |                                |
   |<---------------------------|                                |

HTLC rejected after funding

 Alice                         Bob                             Carol
   |       update_add_htlc      |                                |
   |  amount = 50_100_000 msat  |                                |
   |--------------------------->|                                |
   |                            |      propose_funding_htlc      |
   |                            |    amount = 50_000_000 msat    |
   |                            |------------------------------->|
   |                            |      accept_funding_htlcs      |
   |                            |<-------------------------------|
   |                            |          splice_init           |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |------------------------------->|
   |                            |          splice_ack            |
   |                            |<-------------------------------|
   |                            |         channel_ready          |
   |                            |------------------------------->|
   |                            |         channel_ready          |
   |                            |<-------------------------------|
   |                            |         update_add_htlc        |
   |                            |    amount = 49_000_000 msat    |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |------------------------------->|
   |                            |        update_fail_htlc        |
   |                            |<-------------------------------|
   |      update_fail_htlc      |                                |
   |<---------------------------|                                |
   |       update_add_htlc      |                                |
   |  amount = 20_200_000 msat  |                                |
   |--------------------------->|                                |
   |                            |         update_add_htlc        |
   |                            |    amount = 19_500_000 msat    |
   |                            |   funding_fee = 500_000 msat   |
   |                            |------------------------------->|
   |                            |      update_fulfill_htlc       |
   |                            |<-------------------------------|
   |    update_fulfill_htlc     |                                |
   |<---------------------------|                                |
   |       update_add_htlc      |                                |
   |  amount = 10_001_000 msat  |                                |
   |--------------------------->|                                |
   |                            |         update_add_htlc        |
   |                            |    amount = 9_500_000 msat     |
   |                            |   funding_fee = 500_000 msat   |
   |                            |------------------------------->|
   |                            |      update_fulfill_htlc       |
   |                            |<-------------------------------|
   |    update_fulfill_htlc     |                                |
   |<---------------------------|                                |

Disconnect and reconnect

 Alice                         Bob                             Carol
   |       update_add_htlc      |                                |
   |  amount = 50_100_000 msat  |                                |
   |--------------------------->|                                |
   |                            |      propose_funding_htlc      |
   |                            |    amount = 50_000_000 msat    |
   |                            |------------------------------->|
   |                            |      accept_funding_htlcs      |
   |                            |               X----------------|
   |      update_fail_htlc      |                                |
   |<---------------------------|                                |
   |       update_add_htlc      |                                |
   |  amount = 25_100_000 msat  |                                |
   |--------------------------->|                                |
   |                            |      propose_funding_htlc      |
   |                            |    amount = 25_000_000 msat    |
   |                            |------------------------------->|
   |                            |      accept_funding_htlcs      |
   |                            |<-------------------------------|
   |                            |          splice_init           |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |---------------X                |
   |      update_fail_htlc      |                                |
   |<---------------------------|                                |
   |       update_add_htlc      |                                |
   |  amount = 75_500_000 msat  |                                |
   |--------------------------->|                                |
   |                            |      propose_funding_htlc      |
   |                            |    amount = 75_000_000 msat    |
   |                            |------------------------------->|
   |                            |      accept_funding_htlcs      |
   |                            |<-------------------------------|
   |                            |          splice_init           |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |------------------------------->|
   |                            |          splice_ack            |
   |                            |               X----------------|
   |      update_fail_htlc      |                                |
   |<---------------------------|                                |
   |       update_add_htlc      |                                |
   |  amount = 30_200_000 msat  |                                |
   |--------------------------->|                                |
   |                            |      propose_funding_htlc      |
   |                            |    amount = 30_000_000 msat    |
   |                            |------------------------------->|
   |                            |      accept_funding_htlcs      |
   |                            |<-------------------------------|
   |                            |          splice_init           |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |------------------------------->|
   |                            |          splice_ack            |
   |                            |<-------------------------------|
   |                            |         channel_ready          |
   |                            |------------------------------->|
   |                            |         channel_ready          |
   |                            |<-------------------------------|
   |                            |         update_add_htlc        |
   |                            |    amount = 29_000_000 msat    |
   |                            |  funding_fee = 1_000_000 msat  |
   |                            |------------------------------->|
   |                            |      update_fulfill_htlc       |
   |                            |<-------------------------------|
   |    update_fulfill_htlc     |                                |
   |<---------------------------|                                |
   |       update_add_htlc      |                                |
   |  amount = 10_050_000 msat  |                                |
   |--------------------------->|                                |
   |                            |         update_add_htlc        |
   |                            |    amount = 10_000_000 msat    |
   |                            |      funding_fee = 0 msat      |
   |                            |------------------------------->|
   |                            |      update_fulfill_htlc       |
   |                            |<-------------------------------|
   |    update_fulfill_htlc     |                                |
   |<---------------------------|                                |

Happened across this by accident today, but since I'm here...

I really like this idea, and think it's a useful thing to add to the protocol. I had one suggestion.

Instead of adding two new messages (proposed_funding_htlc/accept_funding_htlc) do you think you could add data to open_channel2 that includes the proposal of the htlc instead?

We use the commitment_signed message for the initial commitment transactions in splicing/openchannel2, which includes space for htlcs. You could add the offered htlc to the first commitment transaction of that channel, which gets negotiated/signed before the funds are committed to it.

I think this simplifies the flow a lot, plus lets you immediately commit to the offered htlc during the 'negotiation phase' of the channel open. If your peer doesn't send you an initial commitment transaction with the htlc already built into it, you can easily cancel/abort the open negotiation, before any funds get sent/committed to chain. You can also account for the funding_fee in the opening balance of the channel as well (maybe with an option to "prepay" out of the initial HTLC if desired?)

I think doing this removes 3 messages (propose/accept funding htlc + initial update_add_htlc), and insteads adds extra data to the openchannel/splice TLVS.

I also really like the idea of having openchannel include any 'negotiation' details. This would closely match the negotiation behavior that we use for the current liquidity ads specification. (openchannel/acceptchannel as the call/response with an offer + either acceptance or refusal)

The receiving/end node would then just wait until after channel_ready to send update_fulfill_htlc (which iiuc would be ~immediately if zerconf is flagged)

Happened across this by accident today, but since I'm here...

That's impressive, we really can't hide anything on the internet nowadays xD
But it's great that you found it, early feedback is always welcome!

I really like this idea, and think it's a useful thing to add to the protocol. I had one suggestion.

This is in draft mode for now, because I want to do a prototype implementation in Phoenix and get some feedback from the team, but my plan is to share this as a bLIP once we've validated it internally!

Instead of adding two new messages (proposed_funding_htlc/accept_funding_htlc) do you think you could add data to open_channel2 that includes the proposal of the htlc instead?

I think that wouldn't work, because of MPP: we really need to treat those exactly like HTLCs, but for which we don't have a suitable channel. This way the receiver can use its usual HTLC handling logic to decide whether it will accept those HTLCs after more liquidity has been added. As an LSP, you don't know that MPP is being used, only the recipient has that information in the payment onion.

We also don't want to be triggering on-the-fly liquidity on invalid payments, otherwise a malicious sender could force the LSP to do some funding that the recipient doesn't want, and won't pay the fee for.

Even without MPP, I think it's useful to have the possibility of batching: the recipient can wait for "enough" potential payments before asking the other node to add on-the-fly liquidity. That wouldn't be possible if we let the other node initiate the funding flow with open_channel2 / splice_init.

Note that in most of those scenarios, the node asking for liquidity will not contribute to the funding/splice transaction: they won't be able to pay on-chain fees for it, and won't be able to pay the fees for the additional liquidity yet (it will be paid later when receiving HTLCs). That's the main reason why open_channel2 / splice_init must be sent by the funding node.

This way the receiver can use its usual HTLC handling logic to decide whether it will accept those HTLCs after more liquidity has been added. As an LSP, you don't know that MPP is being used, only the recipient has that information in the payment onion.

You could add (multiple) HTLCs to the openchannel2 request, and maybe include in the accept_channel2 which of the list of proposed HTLC's you'd accept in an initial commitment for the new channel. Maybe I'm missing something here though?

Oh I think you'd keep the same openchannel flow that you have?

 Alice                         Bob                             Carol
   |       update_add_htlc      |                                |
   |  amount = 50_100_000 msat  |                                |
   |--------------------------->|                                |
   |                            |          open_channel2         |
   |                            |         (with proposed htlcs in tlv) |
   |                            |------------------------------->|
   |                            |         accept_channel2         |
   |                            |         (with proposed htlcs ack/nack in tlv) |
   |                            |<-------------------------------|
   |                            |         commit_signed          |
   |                            |         (with ackd htlcs incl)          |
   |                            |------------------------------->|
   |                            |         commit_signed          |
   |                            |         (with ackd htlcs incl)          |
   |                            |<-------------------------------|
   |                            |         channel_ready          |
   |                            |------------------------------->|
   |                            |         channel_ready          |
   |                            |<-------------------------------|
   |                            |       update_fulfill_htlc      |
   |                            |       (dont need update_add/is already in initial commitment tx)      |
   |                            |<-------------------------------|
   |    update_fulfill_htlc     |                                |
   |<---------------------------|                                |

One nice thing about this is that it also gets to reuse all the reconnect logic we already have, no need to rethink how to handle new message flows on reconnect.=

You could add (multiple) HTLCs to the openchannel2 request, and maybe include in the accept_channel2 which of the list of proposed HTLC's you'd accept in an initial commitment for the new channel. Maybe I'm missing something here though?

The liquidity provider cannot include multiple HTLCs, because it doesn't know that future HTLCs are expected.
It would create a very weird flow when the recipient is batching or MPP is used, because it would look like the following:

1. Liquidity provider wants to forward an HTLC, there isn't enough liquidity, so they send open_channel2 (or splice_init, which means they need to negotiate quiescence first)
2. The recipient decrypts the payment onion and sees that it is incomplete, so it must reject open_channel2 (by sending error?) but it must keep in-memory the information of this HTLC
3. The liquidity provider receives the error, must cancel the funding flow, but how does it know that it should keep the incoming HTLC instead of failing it?
4. The liquidity provider receives another HTLC to forward to the recipient and sends a new open_channel2 (or splice_init)
5. With that additional HTLC the receiver has the complete payment and sends accept_channel2 (or splice_ack) and requests enough liquidity for those two HTLCs

The two main pain points here are:

1. When using splicing (the most frequent case here) we'll negotiate quiescence every time for no good reason
2. It is very clunky to handle the case where the recipient wants to wait for more HTLCs before requesting inbound liquidity

One nice thing about this is that it also gets to reuse all the reconnect logic we already have, no need to rethink how to handle new message flows on reconnect.

There is nothing to think about with the current proposal: if we disconnect before we initiated a funding flow, we just forget the funding proposals we made (which makes sense, because if the recipient is offline for a while, we may want to change our funding rates when they reconnect). If we had started a funding flow, then we automatically have the reconnect logic of interactive-tx that lets us finalize the flow.

Fundamentally, I think it makes more sense to mimick the HTLC flow (update_add_htlc -> propose_funding_htlc followed by update_fail_htlc -> fail_funding_htlc or update_fulfill_htlc -> accept_funding_htlcs) and conclude it with an on-chain operation (open_channel2 or splice_init) rather than trying to incorporate the HTLC flow inside the on-chain funding messages.

But maybe it shows that my naming for the new messages is bad, because it ties them too much to on-chain funding?

I tried to prototype this, and it turns out that keeping track of the "debt" owed to the LSP introduces a lot of complexity, because it needs to be:

• potentially spread across HTLCs (when MPP is used and small HTLCs come in)
• transferred to future HTLCs when the debt-paying HTLCs are failed by the recipient

This makes it impossible to link a given on-chain transaction to a specific invoice, and forces the LSP to have weird policies on HTLC relay when too much debt is owed.

So I decided to instead specify Thomas Voegtlin's proposal of explicitly prepaying for additional on-chain funding (once we have Bolt 12 support), and it is much simpler: https://gist.github.com/t-bast/69018875f4f95e660ec2cbbc80f711a6