> > 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. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
