[Lightning-dev] Proof of payment (Re: AMP: Atomic Multi-Path Payments over Lightning)

ZmnSCPxj ZmnSCPxj at protonmail.com
Tue Feb 13 14:23:37 UTC 2018


Good morning Corne and Conner,

Ignoring the practical matters that Corne rightly brings up, I think, it is possible to use ZKCP to provide a "stronger" proof-of-payment in the sense that Conner is asking for.

All that is needed is to create a message (possibly in some standard language) indicating the payment amount and whatever commitment the payee claims to have for this payment, have the payee securely sign the message, and encrypt them.  The encryption key used is hashed and is used as the payment hash for a standard BOLT11.  Together with the standard BOLT11 the payee provides the encrypted message and signature to the payer in some secure communication channel that is end-to-end encrypted (so that only the payer can receive the encrypted message).

(additionally zk-SNARKs attesting to correct operation of the parsing and encryption of the message, as well as the hashing of the encryption key, will be needed)

In order to claim the payment on-Lightning, the payee provides the encryption key (as it is the preimage for the payment hash).  Standard LN routing protocols then propagate this encryption key back to the payer.

As only the payer received the encrypted message, only the payer can decrypt that message using the payment preimage, even if the preimage was propagated to multiple hops (and may very well have been published onchain in case a hop resolved a channel onchain).

Regards,
ZmnSCPxj


-------- Original Message --------
 On February 13, 2018 10:33 AM, Corné Plooy via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:

>Hi Conner,
>
>
> I do believe proof of payment is an important feature to have,
> especially for the use case of a payer/payee pair that doesn't
> completely trust each other, but does have the possibility to go to court.
>
>
> However, I'm not convinced by what you wrote. I do think a combination
> of signed invoice + preimage is a reliable proof of payment. Strictly
> speaking, you are right: it is not so much a proof that they payer
>sent the funds, but it is proof that the payee received the funds.
> This is because the only scenario where it makes sense for the payee to
> reveal the preimage is if it can claim a corresponding incoming HTLC
> with (at least) the correct amount of funds. Revealing the preimage in
> any other scenario would be stupid(), and no amount of cryptography can
> protect against stupidity. So, when it comes to cryptographic proof,
> this is about as good as it gets.
>
>
> Now, about the difference between the payer having sent the funds and
> the payee having received the funds: I'd argue that it's the second that
> really matters. If the payer can prove that there is any kind of
> arrangement that ended up with the payee having received the correct
> amount of funds, that should count as payment. Now, if none of the
> intermediaries has been stupid, this does imply that the payer ends up
> on the sending side of the payment, but even if one if the
> intermediaries has been stupid, why should the payer and payee care? All
> that matters is that an arrangement has been made to let the payee
> receive (at least) the correct amount of funds, and that arrangement has
> been proven to be successful. I consider that proof of payment.
>
>
> CJP
>
>
> () Stupidity includes being hacked, and anything else that can cause
> your secrets being used against your own interests.
>
>
> Op 13-02-18 om 04:29 schreef Conner Fromknecht:
>>Hi everyone,
>>I've seen some discussions over losing proofs of payment in the AMP
>> setting,
>> and wanted to address some lingering concerns I have regarding the
>> soundness of using the current invoicing system to prove payments.
>>In general, I think we are ascribing too much weight to simply having a
>> preimage and BOLT 11 invoice. The structure of non-interactive payments
>> definitely poses some interesting challenges in adapting the existing
>> invoicing
>> scheme. However, I believe there exist stronger and better means of doing
>> proofs of payment, and would prefer not to tie our hands by assuming
>> this is the best way to approach the problem.
>>IMHO, the current signed invoice + preimage is a very weak proof of
>> payment.
>> It's the hash equivalent to proving you own a public key by publishing the
>> secret key. There is an assumption that the only way someone could get
>> that
>> preimage is by having made a payment, but this assumption is broken most
>> directly by the proving mechanism. Similarly, any intermediary who
>> acquires
>> an invoice with the appropriate hash could also make this claim since they
>> also have the preimage.
>>Further, I think it's a mistake to conflate
>>   1) me being able to present a valid preimage/invoice pair, with
>>   2) me having received the correct preimage in response to an onion
>> packet
>>     that I personally crafted for the receiving node in the invoice. 
>>
>> The main issue is that the proof does not bind a specific sender,
>> making statement 1 producible by multiple individuals. I think it would be
>> potentially worthwhile to explore proofs of stronger statements, such
>> as 2,
>> that could utilize the ephemeral keys in the onion packets, or even the
>> onion as a witness, which is more rigidly coupled to having actually
>> completed a payment.
>>Without any modification to the spec, we can always use something like
>> ZKBoo to prove (w/o trusted setup) knowledge of a preimage without
>> totally revealing it to the verifier. This isn't perfect, but at least
>> gives the
>> sender the option to prove the statement without necessarily giving up
>> the preimage.
>>TL;DR: I'm not convinced the signed invoice + hash is really a good
>> yardstick
>> by which to measure provability, and I think doing some research into
>> proofs
>> of payment on stronger statements would be incredibly valuable. Therefore,
>> I'm not sure if AMPs really lose this, so much as force us to reconsider
>> what it actually requires to soundly prove a payment to an external
>> verifier.
>>Best,
>> Conner
>>On Mon, Feb 12, 2018 at 6:56 PM ZmnSCPxj via Lightning-dev
>> <lightning-dev at lists.linuxfoundation.org
>>mailto:lightning-dev at lists.linuxfoundation.org> wrote:
>>Good morning Christian and Corne,
>>
>>Another idea to consider, is techniques like ZKCP and ZKCSP, which
>>provide atomic access to information in exchange for monetary
>>compensation.  Ensuring atomicity of the exchange can be done by
>>providing the information encrypted, a hash of the encryption key,
>>and proofs that the encrypted data is the one desired and that the
>>data was encrypted with the given key; the proof-of-payment is the
>>encryption key, and possession of the encryption key is sufficient
>>to gain access to the information, with no need to bring in legal
>>structures.
>>
>>(admittedly, ZKCP and ZKCSP are dependent on new cryptography...)
>>
>>(also, AMP currently cannot provide a proof-of-payment, unlike
>>current payment routing that has proof-of-payment, but that is an
>>eventual design goal that would enable use of ZKC(S)P
>>on-Lightning, assuming we eventually find out that zk-SNARKs and
>>so on are something we can trust)
>>
>>Regards,
>>ZmnSCPxj
>>
>>>>Sent with ProtonMail Secure Email.
>>>>
>>-------- Original Message --------
>> On February 13, 2018 2:05 AM, Christian Decker
>><decker.christian at gmail.com <mailto:decker.christian at gmail.com>>
>>wrote:
>>
>>>Honestly I don't get why we are complicating this so much. We have a
>>> system that allows atomic multipath payments using a single
>>secret, and
>>> future decorrelation mechanisms allow us to vary the secret in
>>such a
>>> way that multiple paths cannot be collated, why introduce a
>>whole set of
>>> problems by giving away the atomicity? The same goes for the
>>overpaying
>>> and trusting the recipient to only claim the owed amount, there
>>is no
>>> need for this. Just pay the exact amount, by deriving secrets
>>from the
>>> main secret and make the derivation reproducible by intermediate
>>hops.
>>>
>>> Having proof-of-payment be presentable in a court is a nice
>>feature, but
>>> it doesn't mean we need to abandon all guarantees we have worked
>>so hard
>>> to establish in LN.
>>>
>>> Corné Plooy via Lightning-dev
>>lightning-dev at lists.linuxfoundation.org
>><mailto:lightning-dev at lists.linuxfoundation.org>
>>>writes:
>>>
>>>>I was thinking that, for that use case, a different signed
>>invoice could
>>>> be formulated, stating
>>>> - several payment hashes with their corresponding amounts
>>>>
>>>> - the obligation of signer to deliver Z if all corresponding
>>payment
>>>> keys are shown
>>>>
>>>> - some terms to handle the case where only a part of the
>>payments was
>>>> successful, e.g. an obligation to refund
>>>>The third item is a bit problematic: in order to distinguish
>>this case
>>>> from a complete success, the payee would have to prove absence of
>>>> successful transactions, which is hard. Absence of successful
>>>> transactions can only be declared by the payer, so in order to
>>reliably
>>>> settle without going to court first, the payer should sign a
>>>> declaration stating that certain transactions were canceled and
>>that the
>>>> other ones should be refunded. This can be another invoice.
>>>>So, the original invoice states:
>>>> - several payment hashes with their corresponding amounts
>>>>
>>>> - if all corresponding payment keys are shown: the obligation
>>of <payee>
>>>> to deliver Z, UNLESS stated otherwise by an invoice signed by
>><payer>
>>>>-- signed by <payee>
>>>>But if a payment partially fails, it can be refunded
>>cooperatively with
>>>> an invoice created by payer:
>>>> - declares which of the original payments were successful (with
>>payment
>>>> keys) and which were not
>>>>
>>>> - replaces the obligation of <payee> to deliver Z with an
>>obligation to
>>>> refund the successful transactions
>>>>
>>>> - several payment hashes with their corresponding amounts
>>>>
>>>> - if all corresponding payment keys are shown: cancel the
>>obligation of
>>>> <payee> to refund
>>>>-- signed by <payer>
>>>>Maybe this can be repeated iteratively if necessary; hopefully the
>>>> not-yet-settled amount will converge to zero.
>>>>Important advantage: this only requires changes to the invoice
>>format,
>>>> not to the network protocol.
>>>>The point is: in this use case, the court is apparently the
>>final point
>>>> of settlement for invoices, just like the blockchain is for the
>>other
>>>> channels in the route. IANAL, but I think the "scripting language"
>>>> accepted by courts is quite flexible, and you can use that to
>>enforce
>>>> atomicity. With the construction described above, you can
>>either refund
>>>> cooperatively (and collect evidence that refund has happened),
>>or, if
>>>> that fails, go to court to enforce settlement there.
>>>>CJP
>>>>Op 12-02-18 om 10:23 schreef Christian Decker:
>>>>>CJP cjp at ultimatestunts.nl <mailto:cjp at ultimatestunts.nl> writes:
>>>>>>Can you give a use case for this?
>>>>>>Usually, especially in the common case that a payment is done in
>>>>>> exchange for some non-cryptographic asset (e.g. physical
>>goods), there
>>>>>> already is some kind of trust between payer and payee. So, if
>>a payment
>>>>>> is split non-atomically into smaller transactions, and only a
>>part
>>>>>> succeeds, presumably they can cooperatively figure out some
>>way to
>>>>>> settle the situation.
>>>>>> The scenario that is commonly used in these cases is a
>>merchant that
>>>>>> provides a signed invoice "if you pay me X with payment_hash
>>Y I will
>>>>>> deliver Z". Now the user performs the payment, learns the
>>payment_key
>>>>>> matching the payment_hash, but the merchant refuses to
>>deliver, claiming
>>>>>> it didn't get the payment. Now the user can go to a court,
>>present the
>>>>>> invoice signed by the merchant, and the proof-of-payment, and
>>force the
>>>>>> merchant to honor its commitment.
>>>>>>
>>>>>Lightning-dev mailing list
>>>>>Lightning-dev at lists.linuxfoundation.org
>><mailto:Lightning-dev at lists.linuxfoundation.org>
>>>>>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>>
>>>>Lightning-dev mailing list
>>>>Lightning-dev at lists.linuxfoundation.org
>><mailto:Lightning-dev at lists.linuxfoundation.org>
>>>>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>Lightning-dev mailing list
>>>Lightning-dev at lists.linuxfoundation.org
>><mailto:Lightning-dev at lists.linuxfoundation.org>
>>>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
>>_______________________________________________
>>Lightning-dev mailing list
>>Lightning-dev at lists.linuxfoundation.org
>><mailto:Lightning-dev at lists.linuxfoundation.org>
>>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>>Lightning-dev mailing list
>>Lightning-dev at lists.linuxfoundation.org
>>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
>Lightning-dev mailing list
>Lightning-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>



More information about the Lightning-dev mailing list