This is particularly relevant in the case of submarine swaps, where there are usually two entities: the user (customer) and the server (swap provider). However, in this proposal, there is an additional entity involved.The proposal requires senders to be aware that the payment will lead to a channel creation or a splice on the receiver's end. This means that all existing software used by senders would need to be updated to support this functionality.To illustrate this concept, let's consider a scenario involving Alice, Bob, and a swap service provider. Alice generates an invoice to receive money on-chain, and Bob wants to pay that invoice via Lightning. In this case, there are three entities: Alice, the swap service provider, and Bob. Only Alice is aware of the presence of the swap server.To facilitate the payment, the swap service provider enables Bob to pay Alice on Lightning, while Alice receives the payment on-chain. The process involves several steps:1. Alice generates a preimage and calculates its hash (RHASH1) for the actual amount she wants to receive.2. Alice contacts the swap server, providing RHASH1 and the corresponding amount.3. The swap server generates another preimage and its hash (RHASH2) for a small prepayment amount.4. The swap server creates a lightning invoice and includes (RHASH1, amount1) and (RHASH2, amount2) in it.5. Alice verifies the lightning invoice, ensuring that it includes the expected amounts and RHASH1.6. Alice shares the invoice with Bob through a side-channel.7. Bob, who is a simple lightning wallet, pays the invoice without needing to know that the node ID signing the invoice does not belong to Alice.8. Bob sees that the invoice contains two payment hashes and amounts, and sends HTLCs to cover both payments.9. The HTLCs arrive at the swap server, which holds them until HTLCs with enough offered money for both the prepayment and the main payment are received.10. The swap server fulfills the HTLCs for the prepayment using the preimage for RHASH2.11. The server creates a swap funding transaction on-chain, paying to a locking script redeemable by the preimage of RHASH1.12. Alice waits until the swap funding transaction is mined and then broadcasts a claim transaction, spending the funding transaction output using the preimage for RHASH1.13. The server fulfills the still pending HTLCs for RHASH1 using this preimage.It's important to note that all the security checks and swap logic are only implemented on Alice's side. Bob, as a simple lightning wallet, only needs to be able to parse and pay this new type of LN invoice that contains two hashes.Another option mentioned in the context is that instead of using a special bolt11 invoice, Alice could create a bip21 URI containing both an on-chain address and the lightning invoice. Thus, Alice would still receive on-chain, but Bob would have the choice to pay on-chain or via lightning.Aside from swaps, another use case mentioned is JIT (Just-in-Time) channels. Similar to the swap example, Alice could negotiate with the service provider to have a JIT channel opened to her, and the HTLC forwarded using that channel. Alice can wait for the channel funding to be mined before releasing the preimage for the main payment by fulfilling the HTLC off-chain.Bob, in this scenario, is unaware of what happens between the service provider and Alice. The only visible aspect for Bob is the longer time it takes for the HTLC to be fulfilled. However, if Alice opts not to wait for confirmations and trusts the server, the delay could be removed.In summary, this proposal suggests extending BOLT-11 to allow invoices to contain two bundled payments with distinct preimages and amounts. It aims to address the need for prepayments in services like submarine swaps and JIT channels. The proposed changes would require updating existing sender software and potentially making the new feature optional during a transition period.In a recent discussion on the lightning-dev mailing list, ThomasV proposed a solution to address the vulnerability of service providers like Boltz to denial-of-service (DoS) attacks. Currently, these providers can be forced to pay on-chain fees by attackers. To protect against this, ThomasV suggested implementing Just-In-Time (JIT) channels, where providers would ask for the preimage of the main payment before opening the channel. This would make them custodians under European MICA regulation.To further improve the system, ThomasV proposed bundling the prepayment and main payment in the same BOLT-11 invoice. With this approach, the BOLT-11 invoice would include two preimages and two amounts. The receiver would wait for both