đź“… Original date posted:2023-06-20
🗒️ Summary of this message: Bastien argues for a prepayment solution based on Bolt 12 for Lightning service providers, but Thomas questions the need to rush and suggests a feature bit for optional prepayment.
đź“ť Original message:
Hi Thomas,
> I believe pre-payment of the mining fee can be combined with 0-conf;
> I am not sure why you picture them as opposed? Even with BOLT-12, I
> don't see 0-conf going away.
Sorry if that was unclear, that's not at all what I meant. What I meant
is that if we *stopped* using 0-conf for some reason, the solution I
described wouldn't work anymore and we would have to use a prepayment.
> Would you care to describe whether bundled payments already would
> work with the current specification, or whether they would require
> changes to BOLT-12?
That would require adding a TLV field to Bolt 12 invoices, or a TLV
field to onion messages. The design space for a prepayment solution
based on Bolt 12 is larger than with Bolt 11: I believe we can come
up with a more satisfying protocol.
> I believe that it will take years *after it is merged*, until BOLT-12
> actually becomes the dominant payment method on Lightning. OTOH, if
> this feature was adopted in BOLT-11, I think it could be deployed much
> faster.
I'm not sure why you think it would be faster using Bolt 11? It does
require all sender and receiver software to be updated, and implementers
are currently focused on Bolt 12 so I find it less likely that they
will prioritize work on extensions to Bolt 11 (but I could be wrong).
> The goal of my proposal is to level the field of competition between
> Lightning service providers
I agree that it would be great to have a more satisfying solution than
what currently exists, but this is not a reason to rush it. I think
it's worth trying to build this on top of Bolt 12, where we can
probably do something cleaner since invoices are delivered on-the-fly
and short-lived.
Thanks,
Bastien
Le mar. 20 juin 2023 Ă 10:47, Thomas Voegtlin <thomasv at electrum.org> a
Ă©crit :
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230620/9d8f0c4f/attachment-0001.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-20 23:25:30
in reply to nevent1q…xcnq
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-20 23:25:30Event JSON
{
"id": "eea64d27c0f3f731058d55ae2249082fa21af1d81f4bf862a8f1b362bf3cb461",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1687303530,
"kind": 1,
"tags": [
[
"e",
"043a2b35dbcb1356289d59114e00fee40fb32cc69bf8e3d2ab2d8da4ebc027ca",
"",
"root"
],
[
"e",
"55e416c498cc6a6d921aa088a8a7e21235e47e1a47d33b32a1b3cf29ad1f4eaa",
"",
"reply"
],
[
"p",
"1c5c2782fb587de6b48cd94ee092a282fafb53b0b9f329b4120ea07c8666a07e"
]
],
"content": "📅 Original date posted:2023-06-20\n🗒️ Summary of this message: Bastien argues for a prepayment solution based on Bolt 12 for Lightning service providers, but Thomas questions the need to rush and suggests a feature bit for optional prepayment.\n📝 Original message:\nHi Thomas,\n\n\u003e I believe pre-payment of the mining fee can be combined with 0-conf;\n\u003e I am not sure why you picture them as opposed? Even with BOLT-12, I\n\u003e don't see 0-conf going away.\n\nSorry if that was unclear, that's not at all what I meant. What I meant\nis that if we *stopped* using 0-conf for some reason, the solution I\ndescribed wouldn't work anymore and we would have to use a prepayment.\n\n\u003e Would you care to describe whether bundled payments already would\n\u003e work with the current specification, or whether they would require\n\u003e changes to BOLT-12?\n\nThat would require adding a TLV field to Bolt 12 invoices, or a TLV\nfield to onion messages. The design space for a prepayment solution\nbased on Bolt 12 is larger than with Bolt 11: I believe we can come\nup with a more satisfying protocol.\n\n\u003e I believe that it will take years *after it is merged*, until BOLT-12\n\u003e actually becomes the dominant payment method on Lightning. OTOH, if\n\u003e this feature was adopted in BOLT-11, I think it could be deployed much\n\u003e faster.\n\nI'm not sure why you think it would be faster using Bolt 11? It does\nrequire all sender and receiver software to be updated, and implementers\nare currently focused on Bolt 12 so I find it less likely that they\nwill prioritize work on extensions to Bolt 11 (but I could be wrong).\n\n\u003e The goal of my proposal is to level the field of competition between\n\u003e Lightning service providers\n\nI agree that it would be great to have a more satisfying solution than\nwhat currently exists, but this is not a reason to rush it. I think\nit's worth trying to build this on top of Bolt 12, where we can\nprobably do something cleaner since invoices are delivered on-the-fly\nand short-lived.\n\nThanks,\nBastien\n\nLe mar. 20 juin 2023 à 10:47, Thomas Voegtlin \u003cthomasv at electrum.org\u003e a\nécrit :\n\n\u003e Hello Dave,\n\u003e\n\u003e That is an interesting idea; it would indeed save space for the prepayment\n\u003e hash.\n\u003e I think the invoice would still need a feature bit, so that the receiver\n\u003e can\n\u003e decide to make prepayment optional or required.\n\u003e\n\u003e Note that for the feature to be optional, we need to subtract the\n\u003e prepayment\n\u003e amount from the main payment amount. Thus, in your example, Alice would\n\u003e expect\n\u003e to receive either:\n\u003e (1 BTC, invoice payment_hash)\n\u003e or:\n\u003e (1 BTC - minus 10k sats, invoice payment_hash) + (10k sats,\n\u003e prepayment_hash via keysend)\n\u003e\n\u003e cheers\n\u003e\n\u003e Thomas\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On 19.06.23 22:29, David A. Harding wrote:\n\u003e \u003e On 2023-06-12 22:10, Thomas Voegtlin wrote:\n\u003e \u003e\u003e The semantics of bundled payments is as follows:\n\u003e \u003e\u003e - 1. the BOLT-11 invoice contains two preimages and two amounts:\n\u003e \u003e\u003e prepayment and main payment.\n\u003e \u003e\u003e - 2. the receiver should wait until all the HTLCs of both payments\n\u003e \u003e\u003e have arrived, before they fulfill the HTLCs of the pre-payment. If the\n\u003e \u003e\u003e main payment does not arrive, they should fail the pre-payment with a\n\u003e \u003e\u003e MPP timeout.\n\u003e \u003e\u003e - 3. once the HTLCs of both payments have arrived, the receiver\n\u003e \u003e\u003e fulfills the HTLCs of the prepayment, and they broadcast their\n\u003e \u003e\u003e on-chain transaction. Note that the main payment can still fail if the\n\u003e \u003e\u003e sender never reveal the preimage of the main payment.\n\u003e \u003e\n\u003e \u003e Hi Thomas,\n\u003e \u003e\n\u003e \u003e Do you actually require a BOLT11 invoice to contain a payment hash for\n\u003e \u003e the prepayment, or would it be acceptable for the prepayment to use a\n\u003e \u003e keysend payment with the onion message payload for the receiver\n\u003e \u003e indicating what payment hash to associate with the prepayment (e.g.,\n\u003e \u003e Alice wants to receive 1 BTC to hash 0123...cdef with a prepayment of\n\u003e \u003e 10k sats, so the 10k sats is sent via keysend with metadata indicating\n\u003e \u003e the receiver shouldn't claim it until they receive the 1 BTC HTLC to\n\u003e \u003e 0123...cdef).\n\u003e \u003e\n\u003e \u003e If so, I think then you'd only need BOLT11 invoices to be extended with\n\u003e \u003e an extra_fee_via_keysend field. That would be significantly smaller and\n\u003e \u003e it also allows encoding the extra_fee_via_keysend field in an existing\n\u003e \u003e BOLT11 field like (d) description or the relatively new (m) metadata\n\u003e \u003e field, which may allow immediate implementation until an updated version\n\u003e \u003e of BOLT11 (or an alternative using offers) becomes widely deployed.\n\u003e \u003e\n\u003e \u003e Thanks,\n\u003e \u003e\n\u003e \u003e -Dave\n\u003e\n\u003e --\n\u003e Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany\n\u003e Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636\n\u003e Geschäftsführer: Thomas Voegtlin\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230620/9d8f0c4f/attachment-0001.html\u003e",
"sig": "bd43fd49f70ea06c27fa8aed549a6feac285ed0e216b062ff85cd66a49ac09544a9a807bf5bef1212662c7be3af97a8ba55dae5aeabf7af056a31b2822d32a25"
}