From ZmnSCPxj at protonmail.com  Thu Nov 29 09:49:04 2018
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Thu, 29 Nov 2018 09:49:04 +0000
Subject: [Lightning-dev] [DRAFT] Multi-cell-hop onion with TLV (and
	example for multi-part-payment)
In-Reply-To: <874lc0ieal.fsf@rustcorp.com.au>
References: <874lc2vyoo.fsf@rustcorp.com.au>
	<GiloepFSpPcMjl6ZvTCyb-EAGtj6-u_HpLKSaUorKxx7PiSdu3ciOm04C3zhlJdjKllKm1Fv6mm5J7hGLKkrbRa-pu14fd9Lnjz-SkWaz-g=@protonmail.com>
	<874lc0ieal.fsf@rustcorp.com.au>
Message-ID: <RoKGbNSD7ylLGhpY3R-mofkYVCMdmlz5QiebU_oac1pWnH1wBO2O01Z_XlHhuWbuOhdoQ6nKFc0srV7MlZOdtmGbCLcbr4-7FFFrdIocf8k=@protonmail.com>

Good morning Rusty,

> > On another topic, how about:
> >
> > -   type 6: `application_data`
> >     length: variable
> >     value: unknown
> >
> >
> > Writer MUST only use for final hop, and only if it knows that the final hop has a specific application that it is compatible with.
> > Reader MUST pass this application data to higher layers.
> > The application is responsible for identifying the correctness and validity of the attached value.
> > (It seems to me that this would work for spontaneous payments to identify who the sender is, e.g. exchanges might provide a userkey and authorization that will be wrapped in this TLV; a corresponding new field in BOLT11 invoices (or multi-use offers) can specify the `application_data` to use for the payment, for example)
>
> I don't think that the BOLT11 invoice should specify it; the invoice is
> uniquely tied to the payment already, and having another one just adds
> confusion and seems like it might tempt people to do dumb things.
>
> I can imagine using this for (non-provable) games of chance
> (LightningDice anyone?); the user picks a random number and puts it in
> here. Some new lightning RPC API allows them to provide this as well as
> the bolt11 invoice: the merchant pays out if the random number matches
> the preimage.

The intent is to combine the multi-use offer with `spontaneous_payment`.

I do not remember well if it was at summit or on-list, and am too lazy to dig up the detail, but, somebody mentioned the use of spontaneous payment when interacting with trust-demanding third parties, like banks that hold Bitcoin on behalf of their "customers".
This is precisely the correct sacrifice of proof-of-payment, because trust is demanded anyway and you have no recourse.
It was also mentioned that some data would need to be delivered by the payer in order for the bank to identify the "account number" to credit.

Thus it would be useful for the bank to provide a multi-use offer, containing the `application_data` (the account number or some identifier of the account holder).
Then it would be used by the bank customer, by providing a `spontaneous_payment` below.


>
> > -   type 8: `spontaneous_payment`
> >     length: 32
> >     value: preimage
> >
> >
> > Writer MUST only use for final hop, and sacrifices proof-of-payment.
> > Reader MUST claim the HTLC using the given preimage.
>
> s/MUST/MAY/? Reader can reject spontaneous payments.

I agree.

I wonder, if this is something that should be advertised on `global_features` also.

Regards,
ZmnSCPxj