Andy Schroder [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-21 📝 Original message: Andy Schroder On ...

📅 Original date posted:2018-03-21
📝 Original message:
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.
>
>
>