He pointed out that even getting amount-less BOLT-11 invoices widely supported has been challenging. He questioned the need for a new incompatible version of BOLT-11 and its potential adoption by the entire ecosystem.Thomas Voegtlin proposed an extension to BOLT-11 in his message. The proposed extension involves allowing an invoice to contain two bundled payments with distinct preimages and amounts. This extension aims to address the use case of services that require prepayment of mining fees for non-custodian exchanges like submarine swaps and JIT channels.Currently, some services can ask for a prepayment due to their software's ability to handle it. However, competitors who do not require a dedicated wallet, such as Boltz exchange, cannot implement this feature. This vulnerability can lead to denial-of-service (DoS) attacks where attackers force them to pay on-chain fees.In the case of JIT channels, providers who want to protect themselves against mining fee attacks must ask for the preimage of the main payment before opening the channel. However, this approach makes the service custodian, which has legal implications under European MICA regulation. Competitors who refuse to offer custodian services are excluded from this market, such as Electrum.To solve these issues, Thomas suggests bundling the prepayment and the main payment in the same BOLT-11 invoice. The proposal outlines the semantics of bundled payments, including waiting for all HTLCs of both payments to arrive before fulfilling the prepayment HTLCs. If the main payment does not arrive, the prepayment is failed with a MPP timeout. Once both payments' HTLCs have arrived, the receiver fulfills the prepayment HTLCs and broadcasts the on-chain transaction. However, there is still a risk of the main payment failing if the sender never reveals its preimage.Thomas acknowledges that this proposal does not prevent service providers from stealing the prepayment, but highlights that this risk exists even without the proposed change.He believes that this proposal would level the playing field for competition among Lightning service providers. Currently, using Loop requires a dedicated client, leaving competitors without an established user base vulnerable to mining fee attacks. Additionally, Thomas suggests that ACINQ would benefit from this proposal by making their pay-to-open service fully non-custodian and avoiding falling under European MICA regulation.Lastly, Thomas argues that this change should be implemented in BOLT-11 rather than using BOLT-12 or onion messages. He believes that the proposal does not require the exchange of new messages and that adding unnecessary complexity should be avoided.Overall, the discussion revolves around the extension of BOLT-11 to address the need for bundled payments in certain use cases and its potential impact on improving competition among Lightning service providers.