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