Re: [Lightning-dev] Proposal for updateable / revokable proofs of payment
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 [+]: > Good morning CJP, > > It seems to me, naively, that we can encode the description "the > obligation in the invoice whose hash is 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 > 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 > 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
Re: [Lightning-dev] Proposal for updateable / revokable proofs of payment
Good morning CJP, It seems to me, naively, that we can encode the description "the obligation in the invoice whose hash is 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 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 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] Proposal for updateable / revokable proofs of payment
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
