Hello Dave,
That is an interesting idea; it would indeed save space for the prepayment hash.
I think the invoice would still need a feature bit, so that the receiver can
decide to make prepayment optional or required.
Note that for the feature to be optional, we need to subtract the prepayment
amount from the main payment amount. Thus, in your example, Alice would expect
to receive either:
(1 BTC, invoice payment_hash)
or:
(1 BTC - minus 10k sats, invoice payment_hash) + (10k sats, prepayment_hash
via keysend)
cheers
Thomas
On 19.06.23 22:29, David A. Harding wrote:
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
--
Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
