Corné Plooy [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-19 📝 Original message: > > What about enforcing ...

📅 Original date posted:2018-03-19
📝 Original message:
>
> What about enforcing a maximum payment amount that can be refunded?
> Can this help make the amount not a requirement? This way the payment
> amount will still be open to the payer, but it will have a constraint.

I see no use case anymore for leaving out the amount in the invoice. For
any type of transaction where the payer decides the amount, he can do so
by specifying the amount in the invoice request.

>>>      3.  True. Right now I'm thinking in the opposite direction:
>>> simplifying
>>>           BOLT 12 by removing the possibility of refunds. We can
>>> always add it
>>>           back later (with a proper set of features for all kinds of
>>> refunds) as
>>>           an optional feature.
>
>
> I want my refund :-) !
I did some further thinking on refunds. Generally speaking, they are a
solution for when Transactions Get Messy, right? You agreed to a
transaction, the Lightning payment happened, but now you want to change
something. That 'something' can be, for instance, a full refund (e.g. if
goods cannot be delivered), a partial refund (e.g. if goods arrived
later than agreed, or with inferior quality), an extra payment by the
payer (e.g. cheaper model out of stock, decided to buy the more
expensive one instead), or no payment at all (e.g. payer changes mind
after the payment, and wants the black/blue model instead of the
white/gold one, which has the same price).

There is some similarity between a "BOLT 12" transaction that allows
refunds and other updates, and a microtransaction channel. Specifically,
I think you want the new state to be signed by whoever may possibly have
a legitimate interest *against* the update, and you want the old state
to be invalidated. In BOLT 12, to support this, a state should typically
contain the description field, a field that invalidates the previous
state, a field that specifies how this state can be invalidated, and
optionally a payment hash(*), which indicates that this state update is
valid only in combination with the corresponding preimage. A transaction
starts in a "null" state (no obligations between participants), and ends
specifying certain obligations that have been fulfilled. TBD: maybe
returning to null state by signing off that all obligations have been
fulfilled? E.g. payer signing off that ordered goods have been received.
Note that this must be different from canceling the transaction, since
you want the payer to keep some kind of proof of ownership. Anyway, I
think returning to null state should not be required on BOLT12 protocol
level: not everybody wants this. Some suppliers may want to require it
though.

Looking at the protocol for this (generalized) refund usage, it seems
clear that, often, you don't want to have to keep the communication line
open the entire time: it can take days, weeks or longer until the final
settlement of a transaction. You should be able to reconnect (typically
in the same direction as the initial connect) and say "hey, let's update
the state of the transaction to this-or-that". So, on re-connecting, you
also need to be able to specify *which* transaction to update.

The format of the "description" field is unspecified for now; I think
it's best to keep it that way. Machine-readable formats for this are a
very complex subject, better solved at a higher level protocol. For now,
assume it to be human-readable; maybe add a MIME type field so that its
format is both unambiguous (technologically) and upgradeable.

TBD: is there a use case for transactions between more than two parties?
Or having smart contract (scriptless?) scripts? These would then
typically be evaluated by a settlement service provider (e.g. the legal
system) instead of a block chain.

> All return onions still have the same problem of capacity though.
A partial onion is a very generic solution. If capacity is your greatest
concern as payee, you just supply a zero-hop partial onion. Minimum
privacy, but maximum ability of the payer to construct a route over
channels with sufficient capacity. The choice is yours.

>>>      4.  This depends on the use case. The URL contains an optional
>>> invoice
>>>           ID. A payee can request a payment for a specific, single
>>> transaction
>>>           (for a single instance of delivery of goods/services) by
>>> handing over an
>>>           URL, including an invoice ID, to a single payer. This
>>> provides similar
>>>           functionality as BOLT 11, except that you now have a
>>> well-defined
>>>           channel for transmitting larger invoice descriptions and
>>> for using
>>>           partial onion routes. A payee can also hand over an URL
>>> without invoice
>>>           ID; this can be used and re-used by one or more payers,
>>> whenever they
>>>           want to perform payments to this payee.
>> How does the payer derive the payment hash? Or does the payer have to
>> contact the payee again to get a fresh payment hash specifically for
>> the payer?
Contact the payee again. Or, more generally, one of them knows how to
contact the other to propose updates to the agreement; if the payee of
the update agrees, he will provide the payment hash.

CJP

(*) together with amount and timeout: these allow the payer to know
under what conditions the payee is likely to release the preimage.