Conner Fromknecht [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-14 📝 Original message: Hi Paberlance, As ...
📅 Original date posted:2019-06-14
📝 Original message:
Hi Paberlance,
As ZmnSCPxj mentioned, it should be possible to so after TLV and related
dependencies are finalized.
However I don’t think embedding an invoice in the onion is the most
efficient way to do this. Once a spontaneous payments protocol is
established, it should be sufficient to embed, minimally, the sender’s
pubkey, and perhaps some hop hints if the node is private.
Obviously this leaks the sender’s identity, but no more than an invoice
would. IMO leaking the sender’s pubkey in every payment (even ones that
might not be refunded) seems like pretty big drawback. That being said, the
same info could probably be provided externally (or out of band) if the
sender really does want to be refunded and offer better privacy for
non-refunded payments.
Cheers,
Conner
On Thu, Jun 13, 2019 at 23:16 ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Paberlance,
>
> You may be interested in the current work with "TLV" that is on-going at
> the spec level now.
>
> This will allow a sort of key-value map to be sent on every payment.
>
> It would be possible, *once TLV has been finalized*, to propose the
> addition of such data in a Lightning payment.
>
> As of now, there is no easy way to transmit extra application-level data
> on each payment.
>
> The dependencies, as I understand them, are:
>
> refund invoice on payment -> application-specific data TLV -> TLV spec ->
> variable-length onion packet
>
>
> Variable-length onion packet should finalize "soon" for some definition of
> "soon", if my understanding is correct.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, June 14, 2019 1:53 PM, Paberlance via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
> > Hello Lightning Devs,
> >
> > i was wondering about the following idea: What if you attach a refund
> invoice to any LN payment. With this the recipient then has the possibility
> to refund, fully, partially or eventually tipping even a higher payment
> amount back to the sender.
> >
> > From the user side, the userwallet pays just as normal Lightning
> Invoice, but attached along with the payment of 0 sat invoice back to the
> seller. From a UX perspective, this all happens is controlled by the
> wallet, which must agree on a protocol for embedding the return invoice
> with the LN payment.
> >
> > On the recipee side, a normal LN invoice is recieved and optionally
> store that invoice to be able to perform a spontaneous refund later in time
> if he wants.As the invoice amount is not predefined, the seller is free to
> refund any payment, just bounded to the invoice timeout. Probably the payer
> will be motivated to issue invoices with a high expiry time-out.
> >
> > Possible Usecases:
> >
> > *Promotions, like: Every 100x Purchaser wins a prize, gets the order for
> free.
> >
> > *Refunds: I order something, cancel the transaction, seller refunds the
> transaction partially, charging a service fee that he does not return.
> >
> > *Safety deposits: You rent a car, the company keeps the payment as
> safety deposit, that gets reverted as soon as the car is returned.
> >
> > *Spontanous payouts in games
> >
> > Alternatives:
> >
> > *Hodl invoice, can achieve the same goal to refund the customer, but
> limited as it's an "all or nothing refund" option. Amount can't be more
> than the actual payment.
> > https://github.com/lightningnetwork/lnd/pull/2022
> >
> > *"Spontaneous LN invoice creation " with server that acts as a lookup
> proxy that handles the lightning creation on request. Inspiration:
> @georgevaccaro
> >
> > Requirements:
> >
> > Payer has to generate a invoice and provide it encoded in the payment
> request as payload.
> > Reciver: must be able to settle the actual payment. And optionaly he may
> support the feature After storing the refund invoice, he then has the
> ability to decice if or how he will use it to refunde the client in the
> future.
> >
> > Does this exist yet? What people can help me with this idea?
> >
> > Any ressources or hints to digg deeper, built on top of that idea?
> >
> > Paberlance
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
—Sent from my Spaceship
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190613/3ebd8d8a/attachment-0001.html>;
📝 Original message:
Hi Paberlance,
As ZmnSCPxj mentioned, it should be possible to so after TLV and related
dependencies are finalized.
However I don’t think embedding an invoice in the onion is the most
efficient way to do this. Once a spontaneous payments protocol is
established, it should be sufficient to embed, minimally, the sender’s
pubkey, and perhaps some hop hints if the node is private.
Obviously this leaks the sender’s identity, but no more than an invoice
would. IMO leaking the sender’s pubkey in every payment (even ones that
might not be refunded) seems like pretty big drawback. That being said, the
same info could probably be provided externally (or out of band) if the
sender really does want to be refunded and offer better privacy for
non-refunded payments.
Cheers,
Conner
On Thu, Jun 13, 2019 at 23:16 ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Paberlance,
>
> You may be interested in the current work with "TLV" that is on-going at
> the spec level now.
>
> This will allow a sort of key-value map to be sent on every payment.
>
> It would be possible, *once TLV has been finalized*, to propose the
> addition of such data in a Lightning payment.
>
> As of now, there is no easy way to transmit extra application-level data
> on each payment.
>
> The dependencies, as I understand them, are:
>
> refund invoice on payment -> application-specific data TLV -> TLV spec ->
> variable-length onion packet
>
>
> Variable-length onion packet should finalize "soon" for some definition of
> "soon", if my understanding is correct.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, June 14, 2019 1:53 PM, Paberlance via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
> > Hello Lightning Devs,
> >
> > i was wondering about the following idea: What if you attach a refund
> invoice to any LN payment. With this the recipient then has the possibility
> to refund, fully, partially or eventually tipping even a higher payment
> amount back to the sender.
> >
> > From the user side, the userwallet pays just as normal Lightning
> Invoice, but attached along with the payment of 0 sat invoice back to the
> seller. From a UX perspective, this all happens is controlled by the
> wallet, which must agree on a protocol for embedding the return invoice
> with the LN payment.
> >
> > On the recipee side, a normal LN invoice is recieved and optionally
> store that invoice to be able to perform a spontaneous refund later in time
> if he wants.As the invoice amount is not predefined, the seller is free to
> refund any payment, just bounded to the invoice timeout. Probably the payer
> will be motivated to issue invoices with a high expiry time-out.
> >
> > Possible Usecases:
> >
> > *Promotions, like: Every 100x Purchaser wins a prize, gets the order for
> free.
> >
> > *Refunds: I order something, cancel the transaction, seller refunds the
> transaction partially, charging a service fee that he does not return.
> >
> > *Safety deposits: You rent a car, the company keeps the payment as
> safety deposit, that gets reverted as soon as the car is returned.
> >
> > *Spontanous payouts in games
> >
> > Alternatives:
> >
> > *Hodl invoice, can achieve the same goal to refund the customer, but
> limited as it's an "all or nothing refund" option. Amount can't be more
> than the actual payment.
> > https://github.com/lightningnetwork/lnd/pull/2022
> >
> > *"Spontaneous LN invoice creation " with server that acts as a lookup
> proxy that handles the lightning creation on request. Inspiration:
> @georgevaccaro
> >
> > Requirements:
> >
> > Payer has to generate a invoice and provide it encoded in the payment
> request as payload.
> > Reciver: must be able to settle the actual payment. And optionaly he may
> support the feature After storing the refund invoice, he then has the
> ability to decice if or how he will use it to refunde the client in the
> future.
> >
> > Does this exist yet? What people can help me with this idea?
> >
> > Any ressources or hints to digg deeper, built on top of that idea?
> >
> > Paberlance
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
—Sent from my Spaceship
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190613/3ebd8d8a/attachment-0001.html>;