Thomas Voegtlin [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-20 🗒️ Summary of this message: Thomas suggests ...

📅 Original date posted:2023-06-20
🗒️ Summary of this message: Thomas suggests adding a feature bit to the invoice to make prepayment optional or required, and subtracting the prepayment amount from the main payment amount.
📝 Original message:
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