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 <c...@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@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
