Andy Schroder
On 03/19/2018 08:06 AM, Corné Plooy wrote:
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.
Maybe you are right.
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).
Did you take a look a the application in my link? It demonstrates paying
for fuel for an automobile with bitcoin using blockchain payments. There
is first a payment and then the pump powers on. After the person
finishes dispensing fuel into their vehicle, it immediately places a
refund transaction using the refund address received using the BIP70
payment protocol. It even uses NFC and bluetooth instead of QR codes and
http. Most automobile owners have to go through this payment process
every 5-15 days if they buy fuel with cash. It's not really a messy
transaction and their is no any way to know with much accuracy how much
fuel they actually need since fuel level gauges in automobiles aren't
very inaccurate. And, you can always be filling up some cans of unknown
size to take back and refill your tractor, generator, boat, or whatever.
This is a situation where you shouldn't need to divulge your identity to
make a trivial purchase of a commodity.
Other common examples include making a deposit for a hotel. Normally you
need to put something up far beyond the cost of the room rental in order
to cover any damages you could make to the room. Same goes for renting
anything really. There are many other little cases where you may need to
place a deposit greater than the cost of the good/service you are receiving.
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.
Makes sense.
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.
Interesting thought.
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.
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
