CJP [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-05 📝 Original message: I think it's true that ...

📅 Original date posted:2018-11-05
📝 Original message:
I think it's true that most of my proposal can be achieved by writing
such things in human-readable form in the description field. Mostly,
the only thing my proposal does is to put things into a machine-
readable form; this may aid in automated processing and maybe a better
UI experience.

Maybe the least trivial thing is the inclusion of a payer pubkey in the
original invoice; this is the least trivial both in protocol complexity
and in potential benefits. One benefit is that it turns a "proof-that-
someone-paid" into a "proof-that-I-paid"; another benefit is that it
becomes clear who is authorized to issue another invoice that says
"this original invoice is nullified".

Now that I think of it: my proposal has something important that yours
doesn't: the requirement to have *two* signatures (both payer and
payee) on each update. Without that requirement, there is one party who
can nullify the old contract by making a unilaterally signed invoice
and a self-generated payment preimage. Not even a need to do a payment
to self to "fake" a sort of a refund payment or so. This may be OK as
long as there is only one party who has obligations: then the other
party may partially or completely nullify those obligations, optionally
dependent on a payment. Requiring two signatures (and thereby
consensus) on each update is more generic though: it allows for
obligations on both parties.

Even more generic could be to allow more than two parties. I'm sure
there are complex business arrangements that have a need for this, but
I think we can always develop that later. Let's first tackle this
relatively simple case.

CJP


ZmnSCPxj schreef op ma 05-11-2018 om 01:20 [+0000]:
> 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
>
>