Bastien expresses his belief that even with BOLT-12, 0-conf will not be eliminated. Thomas seeks clarification on whether bundled payments would work with the current specification or require changes to BOLT-12. Bastien suggests adding a TLV field to Bolt 12 invoices or onion messages to enable bundled payments. He also mentions that it may take years for BOLT-12 to become the dominant payment method on Lightning and suggests that if the feature was adopted in BOLT-11, it could be deployed faster. The goal of Bastien's proposal is to level the playing field for Lightning service providers.In a separate email, Thomas responds to David's suggestion regarding the semantics of bundled payments. Thomas explains that the BOLT-11 invoice should contain two preimages and two amounts: a prepayment and a main payment. He further explains that the receiver should wait for all the HTLCs of both payments to arrive before fulfilling the HTLCs of the pre-payment. Once both sets of HTLCs have arrived, the receiver can fulfill the HTLCs of the prepayment and broadcast the on-chain transaction. Thomas then addresses David's question about using a keysend payment for the prepayment instead of including it in the BOLT11 invoice. He suggests that it would be acceptable and proposes extending BOLT11 invoices with an extra_fee_via_keysend field. This approach would be smaller in size and allow for immediate implementation until an updated version of BOLT11 becomes widely deployed.Overall, the conversation revolves around the possibility of combining pre-payment with 0-conf in Lightning Network, the potential use of bundled payments, and the advantages and challenges of implementing these features in BOLT-12 and BOLT-11. The goal is to provide a more satisfying payment solution and level the competition between Lightning service providers.