David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-19 🗒️ Summary of this message: Thomas Voegtlin ...

📅 Original date posted:2023-06-19
🗒️ Summary of this message: Thomas Voegtlin explains the semantics of bundled payments, which involves a BOLT-11 invoice containing two preimages and two amounts.
📝 Original message:
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