BOLT-11: add optional feature bit to indicate delayed settlement of invoice

[Roasbeef]

One popular pattern across the network today is creating an invoice that may have delayed settlement. By this, I mean instances where the invoices won't be instantly settled once the incoming HTLC arrives. Example of this include: JIT-channels, hodl invoices, types of swaps, async payment flow attempts.

Today wallets don't explicitly know that such an invoice type is being used. This can lead to poor UX, as the sender wallet's expects prompt settlement once the HTLC has been fully extended (payment level ACK is another thing all together). If we add a feature bit or repurpose the payment meta data, then sender wallets can update their UX accordingly.

This feature has been requested by several wallet developers, and also authors of protocols/applications that use delayed settlement.

[TheBlueMatt]

Sadly this needs to be set on more than just invoices - nodes in the path forwarding the payment really need to opt into HTLCs that may be substantially delayed (or they risk their new reputation thing, not to mention get screwed over).

[Roasbeef]

For the wallet to know what's going on, it only needs to be set in invoice. It can even just be in the payment meta data field, what's needed is just a simple standard.

Signalling to the forwarding nodes is an entirely different scope. But ofc nodes can always just drop the bit or otherwise.

[TheBlueMatt]

The point is the sending delay isn't just shitty for the sending wallet, its also shitty for every routing node in the path, and probably much moreso because they were gonna use that liquidity, the sender probably wasn't. If we had to pick one between it being in the invoice and in the onion, I'd say its way more important to signal it in the onion.

[AndySchroder]

Definitely agree this is a problem for wallet UX with HOLD invoices. Zeus has the worst of all wallets I've tested (zeus, phoenix, breez, mutiny, muun, strike, cash app), but the other apps have learned to "deal" with it in different ways.

Not sure that I agree it should be part of the onion. Each node agrees to timelocks. That is their commitment and they should be prepared to wait to any amount up to the timelocks in their contracts. If the time lock is too high for them, they should charge higher fees to deal with the issue. I think there is an upcoming fee market that is also dependent on lock time as there are a lot of use cases for delayed settlement.

[TheBlueMatt]

Not sure that I agree it should be part of the onion. Each node agrees to timelocks. That is their commitment and they should be prepared to wait to any amount up to the timelocks in their contracts

The reality of lightning as it exists today is verrryyy far from this. If nodes were to charge appropriately for the timelocks we'd see fees orders of magnitude higher, which presumably people wouldn't be happy about :). Instead, nodes charge an appropriate fee based on the average reality that they observe (that very few HTLCs actually get held for very long). In fact, with the proposed anti-jamming signaling that it seems like we're gonna slowly move forward with, nodes which hold HTLCs for even a relatively small fraction of the CLTV delta will get punished with reduced reputation and ultimately start getting their HTLCs rejected.

[AndySchroder]

Would like to read any references you have to share on proposed anti-jamming signaling.

[TheBlueMatt]

https://github.com/lightning/blips/pull/27