On 2023-06-12 22:10, Thomas Voegtlin wrote:
The semantics of bundled payments is as follows: - 1. the BOLT-11 invoice contains two preimages and two amounts: prepayment and main payment. - 2. the receiver should wait until all the HTLCs of both payments have arrived, before they fulfill the HTLCs of the pre-payment. If the main payment does not arrive, they should fail the pre-payment with a MPP timeout. - 3. once the HTLCs of both payments have arrived, the receiver fulfills the HTLCs of the prepayment, and they broadcast their on-chain transaction. Note that the main payment can still fail if the sender never reveal the preimage of the main payment.
Hi Thomas, Do you actually require a BOLT11 invoice to contain a payment hash for the prepayment, or would it be acceptable for the prepayment to use a keysend payment with the onion message payload for the receiver indicating what payment hash to associate with the prepayment (e.g., Alice wants to receive 1 BTC to hash 0123...cdef with a prepayment of 10k sats, so the 10k sats is sent via keysend with metadata indicating the receiver shouldn't claim it until they receive the 1 BTC HTLC to 0123...cdef). If so, I think then you'd only need BOLT11 invoices to be extended with an extra_fee_via_keysend field. That would be significantly smaller and it also allows encoding the extra_fee_via_keysend field in an existing BOLT11 field like (d) description or the relatively new (m) metadata field, which may allow immediate implementation until an updated version of BOLT11 (or an alternative using offers) becomes widely deployed. Thanks, -Dave _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
