From corne at bitonic.nl Fri Oct 25 09:10:24 2019 From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=) Date: Fri, 25 Oct 2019 11:10:24 +0200 Subject: [Lightning-dev] Make Me An Offer: Next Level Invoicing Message-ID: Rusty, At the recently held Lightning Conference in Berlin you asked for people to send you use cases / feature requests for the next-generation Lightning invoicing. I already did some work on this back in 2018; that work was interrupted when I started working on other ideas. I believe CDecker is member of some W3C(?) commission on payments, so he may also have ideas on this. My earlier work focused on an interactive protocol for direct communication between payer and payee. This is an old sketch / WIP: https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md I know some people don't like such interaction, but it does make many things easier to accomplish, e.g. rendez-vous routing and stuckless payments. For now, without doing an actual technology proposal, I'd like to share a way of thinking about payer/payee interaction. In my view, a transaction is not a line, it's a circle. Bitcoins go from payer to payee over the Lightning network, and whatever assets/goods/services are paid for go from payee to payer - this closes the circle. Transactions on all hops of the circle should be atomic. Between Lightning hops this is realized with HTLCs. For the payer-payee hop this is generally not possible, as non-cryptographic things generally don't allow you to construct HTLCs on them. Invoices and proofs of payment act as cryptographic representatives of non-cryptographic entities. In a generalized view, the interaction between payer and payee can be seen as a virtual payment channel. Full refunds, partial refunds, update of what goods are to be delivered (which may depend on an additional payment or a partial refund), sending back delivered goods (with refund), are all updates to this virtual channel. Desirable properties of such a channel: * The channel has a state, and that state can be updated. * A state update invalidates the previous state. * By default, a state update requires consent of both parties. We may include a feature where, in the previous state, one party gives consent to allow the other party to unilaterally perform certain types of state updates. * A state update may require a payment of a certain amount in one direction or in the opposite direction. The state update only becomes valid in combination with the corresponding proof of payment. * The state specifies obligations of parties to each other (e.g. "A shall return back to B"). * A state can be "final" in the sense that there should be no more updates in the future. This may not need to be enforced by software or by protocol: it can simply be by convention. If the "final" state requires consent of both parties for an update, any participant can make it final by never signing an update, or even by throwing away the private key used for the channel. The state updating mechanism and its properties require special attention. I think the purpose of the channel is to aid in conflict resolution - it should provide evidence of what is agreed between both parties. There is nothing in an old state that makes it inherently invalid: in fact, at some point in the past it was valid. The only thing that makes it invalid is the presence of a later version. To reveal the truth in conflict resolution, it is necessary that (1) the latest state is revealed (2) it is clear that this latest state is more recent than all other states that are revealed I hope that (1) is likely incentive-wise: typically, incentives of the parties are each other's opposite, so either one party has an interest in revealing an update, or the other party has. I haven't worked out this thought very rigorously though. I think a bit of cryptography can help with (2). One idea is to include sequence numbers in states, another is to include the hash of the previous state. Either way, the possibility remains (cryptographically, maybe not incentive-wise) to mess up the evidence by "forking" the channel: making multiple state updates that have the same parent state. This may be resolved semantically, with rules like "if A unilaterally makes a fork, and both sides are revealed, B may choose which side of the fork is to be considered valid". Some advanced ideas * Contracts between three or more parties. * Merging and joining of contracts in state updates CJP