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