CJP [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-04 📝 Original message: Right now, the only ...

📅 Original date posted:2018-11-04
📝 Original message:
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