[Lightning-dev] Proposal for updateable / revokable proofs of payment

[ZmnSCPxj]

Good morning CJP,

It seems to me, naively, that we can encode the description "the obligation in the invoice whose hash is <h> is nullified", whose meaning then is promoted to "if payment happens, payee has an obligation to ensure that the obligation in the invoice whose hash is <h> is nullified", then we have revokable payments already.  Such a payment may itself be revoked, ad infinitum.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, November 5, 2018 5:08 AM, CJP <cjp at ultimatestunts.nl> wrote:

> Right now, the only defined semantics of the description field in
> BOLT11 is that it SHOULD be "a complete description of the purpose of
> the payment". I think this is a bit vague; maybe this is deliberate?
>
> Anyway, you may also think of a BOLT11 payment request as an option
> contract. If the payment is performed (which can be proven by showing
> the preimage), then payee is bound to the terms and conditions in the
> description. So, then the meaning of a description "one cup of coffee"
> becomes "if payment happens, payee has an obligation to deliver one cup
> of coffee".
>
> A known issue is that payer is not identified in the contract, so it is
> not clear to who the payee has this obligation. As far as I can see,
> the only way to fix this is to have two-way communication, where first
> the payer sends some data to payee (e.g. public key), and then payee
> makes the payment request, including this data. With this established,
> we turn the preimage + payment request from a "proof that someone paid"
> into a "proof that I paid", and therefore also a "proof that payee has
> this obligation to me".
>
> I'm a bit afraid that such proofs are a bit too inflexible for real-
> life applications. I think in real-life there are many cases where you
> need to update / revoke agreements, even after payment.
>
> One example is a full refund: if goods/services cannot be delivered
> somehow, payer+payee might agree to a full refund instead of delivery
> of goods/services. The refund is another payment, with a payment
> request made by the original payer; its contract should state that the
> original payee is no longer bound by the obligations in the original
> contract.
>
> Another example is a partial refund, for instance if only a lower
> quantity or a lower quality of goods/services is delivered. This is
> another payment, but now the new contract replaces the old contract and
> specifies a new, lower set of obligations for the original payee.
>
> Another example is a change of conditions without change of payment,
> for instance when a white/gold dress was ordered, but turned out to be
> unavailable, and payer finds a black/blue dress acceptable as well, at
> equal price. Then you'd just want to replace white/gold in the contract
> by black/blue, without any payment.
>
> I think nearly all cases (including ones not mentioned here) are
> covered by a "contract update" format which includes:
>
> -   the new obligations of the two parties to each other
> -   a secure hash of the previous contract version that is replaced by
>     this one
>
> -   optionally, a payment hash
> -   signatures from both parties
>
>     The contract update is considered valid if and only if
>
> -   the signatures correspond to the pubkeys in the original contract
>     (the first in the chain)
>
> -   the signatures are valid signatures on this contract
> -   the previous contracts in the chain are all valid (except for being
>     invalidated by contract updates)
>
> -   there is no known valid contract that replaces this one
> -   if a payment hash is included, a corresponding payment preimage is
>     provided as well
>
>     The original contract is different in that
>
> -   It does not have a previous contract version (may be zeroed if you
>     want to keep the same format)
>
> -   A set of pubkeys is provided (one of payer, one of payee)
> -   Only payee has obligations, so payee never needs to receive a
>     signature from payer. Payer needs to receive payee's signature, and can
>     trivially add his own signature whenever needed.
>
>     Whenever one payee has obligations to another, the pubkey of the party
>     with obligations has to be verified through some PKI. I consider this
>     to be outside the scope of this concept. Especially in the case that
>     one of the parties never has any obligations, that party may use a new,
>     non-PKI-verified pubkey for the transaction, as a temporary pseudonym.
>
>     There is some conceptual similarity between an updateable proof of
>     payment and a payment channel.
>
>     A potential issue is that, theoretically, the "contract update chain"
>     can fork. The simple solution is "don't do that": either party can stop
>     it from happening by not signing the forking update.
>
>     CJP
>
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev