Add support for bundled payments in BOLT12

[ecdsa]

Is it currently possible to request bundled payments in #798?

Bundled payments is a proposal where several payments, with different amounts and payment hashes, are tied together:

• The payer must send all payments simultaneously and not sequentially.
• The payees should, if possible, either fulfill all payments or none of them.

The goal is to let just-in-time channel providers charge a fee for their service, without exposing themselves to griefing attacks from non-cooperative users.

A non-custodian just-in-time channel provider does not have the preimage of the main payment. Before opening a just-in-time channel to the recipient of a payment, they may want to charge a mining fee for their service, with a second payment hash, that differs from the hash of the main payment. They should wait until they have received all the HTLCs corresponding to both payments, before they fulfill the mining fee payment and only then open the channel to the recipient of the main payment.

For more info see https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003977.html

I believe that the current state of bolt12 does not allow to do that. Would it be possible to extend it?

• one option could be to send several invoices in response to an invoice request, with a field indicating the total number of invoices.
• another option would be to add extra amounts and hashes inside the invoice.

[t-bast]

Bolt 12 doesn't support currently this, and won't support this in the MVP. This may come as a follow-up feature, but it definitely needs more spec work to prove that it would work as intended. I had spent some time trying to specify it in more details (see https://gist.github.com/t-bast/69018875f4f95e660ec2cbbc80f711a6) but I'm not sure how to handle the rather annoying partial payment case (where additional on-chain liquidity is added but the "main" payment still cannot be completed, for example because a concurrent payment "stole" the liquidity).

I'm still not entirely convinced that it is absolutely necessary either. In a world where splicing exists, the counterparty risk only exists for the initial channel creation: after that, additional liquidity can be bought trustlessly using the user's channel balance. It seems that paying fees from future HTLCs or using a swap-in to create the initial channel can be an acceptable solution that has a cleaner spec with less edge cases.